£  NATIONAL  SOFTWARE  WORKS 

<C  TOOL  INTEGRATION  STUDIES 

& 

"  General  Systems  Group,  inc. 


Sponsored  by 

Defense  Advanced  Research  Projects  Agency  (DoD) 
ARPA  Order  No.  3686 


The  views  and  conclusions  contained  in  this  document  are  those  of  the 
authors  and  should  not  be  interpreted  as  necessarily  representing  the 
official  policies,  either  expressed  or  implied,  of  the  Defense  Advanced 
Research  Projects  Agency  or  the  U.S.  Government. 


ROME  AIR  DEVELOPMENT  CENTER 

Air  Force  Systems  Command 

Griffiss  Air  Force  Base,  New  York  13441 


' 

This  report  has  been  reviewed  by  the  RADC  Public  Affairs  Office  (PA)  and 
is  releasable  to  the  National  Technical  Information  Service  (NTIS).  At  NTIS 
^  will  be  releasable  to  the  general  public,  including  foreign  nations. 

RADC-TR-81-309  has  been  reviewed  and  is  approved  for  publication. 


APPROVED:  ..  A  f)  j  • 

PATRICIA  Ji^BASKINGER  0 
Project  Engineer 


Acting  Chief,  Plans  Office 


If  your  address  has  changed  or  if  you  wish  to  be  removed  from  the  RADC 

list,  or  if  the  addressee  is  no  longer  employed  by  your  organization, 
please  notify  RADC(ISCP)  Griffiss  AFB  NY  13441.  This  will  assist  us  in 
maintaining  a  current  mailing  list. 


Do  not  return  copies  of  this  report  unless  contractual  obligations 
on  a  specific  document  requires  that  it  be  returned. 


or  notices 


NATIONAL  SOFTWARE  WORKS  TOOL  INTEGRATION  STUDIES 

General  Systems  Group,  Inc. 


Contractor:  General  Systems  Group,  Inc. 

Contract  Number:  F30602-79-C-0106 

Effective  Date  of  Contract:  12  December  197S 

Contract  Expiration  Date:  15  May  1981 

Short  Title  of  Work:  National  Software  Works  Tool 

Integration  Studies 
Program  Code  Number :  9P10 

Period  of  Work  Covered:  Dec  78  -  Apr  81 

Principal  Investigator:  Normand  Rasmussen 
Phone:  603  893-1000 


Project  Engineer: 

Phone: 


Patricia  Baskinger 
315  330-7007 


Approved  for  public  release;  distribution  unlimited. 


This  research  was  supported  by  the  Defense  Advanced 
Research  Projects  Agency  of  the  Department  of  Defense 
and  was  monitored  by  Patricia  Baskinger  (RADC/ISCP), 
Griffiss  APB  NY  13441  under  Contract  F30602-79-C-0106. 


UNCLASSIFIED 


REPORT  DOCUMENTATION  PAGE 


RADC-TR-81-309 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  '*>••«  Dato  Entatad) 


4.  TITLE  Subtitle) 

NATIONAL  SOFTWARE  WORKS  TOOL  INTEGRATION 
STUDIES 


7  AU  T mO  Rf  •) 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


General  Systems  Group,  Inc. 


s  tyre  or  report  a  pcpioo  covered 

Final  Technical  Report 
Dec  78  -  Apr  81 


6  PERFORMING  ORG  REPORT  NUMBER 

N/A 


•  contract  or  grant  NUMBERS! 

F30602-79-C-0106 


9  performing  ORGANIZATION  name  ANO  aooress 

Defense  Advanced  Research  Projects  Agency 
1400  Wilson  Blvd 

Arlington  VA  22209  _ 


11.  CON T POLLING  OFFICE  NAME  ANO  AOORESS 

Rome  Air  Development  Center  (ISCP) 
Grlffiss  AFB  NY  13441 


12  REPORT  O ATI 

November  1981 


is  number  op  pages 

182 


1 4.  MONITORING  AGENCY  NAME  a  AOORESSflf  different  from  Controlling  OHica)  IS.  SECURITY  CLASS,  (ol  thla  t 

UNCLASSIFIED 


is.  distribution  statement  to  I  ihn  Rtponj 


Approved  for  public  reltase;  distribution  unlimited. 


17.  DISTRIBUTION  STATEMENT  (ol  tho  abatract  ontorod  in  Block  20.  II  dllloront  Iroai  Report) 


it.  supplementary  notes 

RADC  Project  Engineer:  Patricia  J.  Baskinger  (ISCP) 


19  KEY  WORDS  f Continue  on  roeoreo  aido  it  nocoaamry  and  identity  by  block  number) 


Network  Operating  Systems 
Software  Systems 
Computer  Network  Resources 


Resource  Sharing 
Operating  Systems 


ABSTRACT  (Continue  on  ro*erer,  aida  II  nacaaaary  and  Idantlly  by  block  nutnbor) 

This  final  technical  report  documents  the  following  specific  activities 
of  the  subject  contract:  (1)  Review  of  the  NSW  project  organizational 
structure,  including  roles,  responsibilities  and  contractor  assignments, 
(2)  Description  of  the  NSW  development  process,  (3)  Survey  of  the  NSW 
system  architecture  and  user  functionality,  (4)  Establishment  of  the 
current  operational  status  of  NSW  including  the  chronology  of  major 
events,  and  finally  (5)  Serve  as  an  Introductory  NSW  tutorial  for  new  -» 


0D  I  jJU“3  1473  edition  OF  I  NOV  «s  IS  obsolete  UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  flWi.n  Oolo  tntorod) 


UNCLASSIFIED 


ttcumrv  CLA»iiyic*riow  or  tmu  ►*oenr»«>  o«. 


UNCLASSIFIED _ 

secuaiTv  CLAjtiriCATioo  or  ru.r  pageitb.*,  d»»  u„u, 


^ users. 


Accession  For 


NTIS  OfcAAI 
DTIC  TAB 
Unannouacod 
Justlf loStl 


By _ _ 

Distribution/ 
Availability  C c -i » s 
.Avail  cun: 
ist  Spec1*.! 


TABLE  Ofr'  CONTENTS 


Page 


1.0  Preface . . . 7 

2.0  Introduction  ......  .  ...  9 

2.1  History  . . . 

2.2  Policy . 15 

3.0  nsw  Project  Organization  .....  .  17 

3.1  Organizational  Structure  ....••••16 

3.2  NSW  Contractors.  . . 20 

4.0  nsm  System  Architecture  •...••.••••••22 

4.1  The  ARPANET  .  . . 23 

4.2  NSW  *  A  Network  Operating  System  ....  28 

4.3  Host  Families . .29 

4.4  nsw  software  Architecture . 30 

4.4.1  NSW  Software  Components  ....  34 

4.4.2  DMC  Responsibilities  .....  36 

4.4.3  Participation  of  Hosts 

In  NSW  Systems  . . 38 

4.4.4  Levels  of  Host  Family 

Participation  . . .40 

4.4.5  The  NSW  User  System 

Configuration  ...  . 42 

5.0  nsw  System  Development  ......  .  45 

5.1  NSW  System  Configurations . .  •  .  48 

5.2  nsw  Testing  Hierarchy  . . 50 

5.3  nsw  system  Release  and  Assessment  ....  51 

5.4  Quality  Assurance  Testing  ..••••••57 

5.5  STR  Processing . . 

5.6  Configuration  Management  ••••••••65 

5.7  NSW  Release  History . 70 

6.0  nsw  user  interface  . . 74 

6.1  Overview  •  .  ••••••75 

6.1.1  Project  management  .  76 

6.1.2  NSW  File  System  ........  85 

6.1.3  NSW  Tools  . . 88 

6.1.4  nsw  Command  Language  •  •  •  •  •  95 


l 


6.2  NSW  User  System  Status  (May  1961)  ....  96 

6.2.1  NSW  Command  Language  Status  •  •  97 

6.2.2  NSW  File  Systea . 98 

6.2.3  NSW  Tools . 102 

6.2.4  User  Documentation . 113 

6.2.5  Future  Directions 

and  Problem  Areas . 115 

6.2.6  nsw  Availability  ......  .117 

7.0  nsw  System  Operations  . . . . 118 

7.1  Overview  of  NSNOPS  Responsibilities  .  119 

7.2  Status  of  NSW  Operations  . . 120 

8.0  AFLC  Technology  Demonstration  .........  .125 

9.0  Notes  and  References . . . 126 

Appendix  a:  GSG  Bibliography  . 130 

Appendix  B:  Generic  Configuration  Items  ......  .133 

Appendix  C:  An  Overview  of  the  NSw  Help  Facility  •  .153 
Appendix  D:  Sample  "weekly  Usage  Report"  .  161 


2 


List  of  Figures  Page 

3*1  nsw  Organizational  Structure . .21 

4-1  Arpanet  Geographic  Nap  .  .  .  .  ,  .  ••••••26 

4-2  ARPANET  Logical  Map  .  . . 27 

4-3  Component  Communication  Via  MSG  . . 32 

4-4  NSW  *  s  Star-Shaped  Control  Structure  . . 33 

4- 5  The  NSW  user  System  Configuration . ••••  .44 

5- 1  Stages  ot  ns*  System  Development  ....... ....47 

5-2  NSW  System  Configurations  ••••..»••»••••  .49 

5-3  ns*  System  Development  Life  Cycle  ....  .  .  .56 

5- 4  STR  Resolution:  Organizational  interactions.  .....  64 

6- 1  Project  Node  A  and  Tool/File  Rights  . . 79 

6-2  Node  A  Creates  Nodes  B.  C  and  . . 80 

6-3  Node  o  Creates  Nodes  DA.  DB  and  DC. .........81 

6-4  Node  A  Deletes  Node  B«...  ............  .82 

6-5  Node  a  Revokes  Node  Creation  Right  from  Node  D  ....  83 

6-6  Node  a  Assigns  File  Riqnt  B.a  to  Node  DB  .  .  .  84 

6-7  Movement  and  Translation  ot  NSW  File  During  EXPORT  .  .  87 
6-8  Assigning  a  workspace  to  An  XED  Tool  Instance  ....  .90 

6-9  File  Movement  and  Translation  Resulting  from  XED  Read  .91 
6-10  Creation  ot  New  File  in  worksoace  .•••••••••92 

6-ii  Modification  of  NSW  File  in  tne  workspace  .  .93 


3 


6-12  Delivery  of  XED  Output  Files  Into  NS*  Fliespece  . 


.  94 


4 


List  of  Tables 


Page 


6-1  Host  Family  rile  Tvoes  . 

6-2  NSM  Tools  by  Host  Family  . 

6-3  Tool  Statistics  by  NSW  Host  and  Tool  Tyoe  •  • 

6-4  Alphabetic  Listing  of  NSW  Tools  by  Host  .  •  • 
6-5  nsw  Tools  by  Generic  Tool  Type  and  Host  .  •  • 


100 

104 

.105 

106 


109 


1.0  Preface 


The  General  Systems  Group  (GSG)  has  been  involved  In  the 
National  Software  Works  (NSW)  project  since  1976.  During  the 
period  1976  -  1981,  GSG  nas  been  awarded  four  (4)  NSW  contracts. 
GSG  *s  participation  in  the  NSW  project  and  responsibilities, 
vis-a-vis  assessment  and  operation  of  the  NSW  system,  nave  grown 
appreciably  during  each  successive  contract  period. 

GSG  has,  in  the  past,  advocated  and  successfully 
demonstrated  the  viability  of  an  independent  testing  and 
operations  organizations  for  the  NSW  system,  based  on  these 
successes,  GSG  was  asked  to  recommend  a  plan  for  managing  the 
development,  operation  and  maintenance  of  the  NSw  software  system 
(11.  GSG 's  recommendation  became  an  integral  part  of  the  "NSW 
Management  Plan"  (2),  prepared  and  distributed  by  the  sponsor 
organizations  (RADC  and  ARPA) •  Implementation  of  this  plan  has 
been  a  major  goal  during  the  present  contract  period  covered  by 
this  report.  This  report  concentrates  heavily  on  the  role  GSG 
has  played  in  implementing  and  evolving  the  system  development 
approach  called  out  by  the  "nsw  Management  Plan".  GSG  is 
contractually  resoonsible  for  fulfilling  tne  following  two  (2) 
roles: 


-  Product  Development  Contractor  (PDC) 

-  nsw  System  Operations  (NSWOPS) 

These  organizations,  staffed  by  GSG  personnel,  are  respectively 
responsible  tor  two  of  the  four  stages  of  the  nsw  system 
velopment  process  (see  section  5.0),  namely: 

-  Productization  and  Quality  Assurance  (PDC),  and 

-  Production  operation  of  the  NSw  system  (NSWOPS). 

This  report  attempts  to  meet  a  number  of  goals 
simultaneously.  Oiscussing  GSG's  NSW  activities  and  documenting 
our  project  contributions  during  the  contract  period  are  one 
goal.  However,  this  report  is  also  intended  to  serve  the 
following  purposes  as  well: 

•  Review  the  nsw  project  organizational  structure. 
Including  roles,  responsibilities  and  contractor 

assignments 

-  Describe  the  NSW  system  development  process 


M 


Survey  NSw *s  system  architecture  and  user  functionality 

Establish  the  current  operational  status  of  NSw; 
indicate  the  major  chronology  of  events. 

Serve  as  an  introductory  nsw  tutorial  for  new  users. 
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2.0  Introduction 


The  National  Software  work*  (NSW)  is  a  pioneering  R  £  D 
project,  jointly  sponsored  by  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  and  the  Air  Force.  The  NSW  system  is  a 
network  operating  system  which  attempts  to  achieve  Integrated 
resource  snaring  in  a  heterogeneous  computer  networking 
environment. 

A  computer  network  is  a  collection  of  autonomous  computers, 
called  "hosts",  interconnected  by  a  common  communications 
subsystem.  Hosts  may  be  geographically  dispersed  (l.e.,  tens, 
hundreds  or  even  thousands  of  miles  apart),  and  of  widely 
different  make  and/or  manufacture.  Computers  of  different 
manufacture  are  usually  software  incompatible.  That  is,  programs 
which  run  on  one  computer  will  not  be  readily  portable  to  another 
for  execution.  Also,  the  syntax  and  interpretation  of  stored 
data  (programs  and  the  data  on  which  they  operate)  vary 
considerably.  Such  incompatibilities  manifest  themselves  as 
differences  in: 

-  Hardware  architecture  and/or 

-  Operating  system,  including 

Program  execution  environment 
File  system,  and 
Command  language 

The  communications  subsystem  of  a  network  provides  a  medium 
tor  the  exchange  of  information  between  host  computers.  The 
communications  subsystem  serves  as  the  foundation  on  which  more 
sophisticated  conversations  (often  called  "protocols”),  between 
host  computer  entities  (i.e.»  executing  programs)  may  be 
implemented.  Protocols  have  been  developed  to  provide  a  wide 
variety  of  network  services  and  functions,  including: 

•  User  access  to  other  network  hosts  (and  their 
resources) 

•  Movement  of  files  from  one  host  computer  to  another 

-  Network  electronic  mail 

NSW  is  a  protocol-oriented  system,  augmenting  and  extending  the 
functions  provided  by  existing  network  protocols. 


Single  host  computers  are  often  viewed  abstractly  as  a 
collection  of  computing  resources  which  may  be  parceled  out  to 
computing  "tasks".  In  the  course  of  a  "task's*  lifetime,  many 
different  computing  system  resources  may  be  raguired  to  complete 
a  given  computational  "task";  the  following  are  representative 
examples: 

-  Storage  and  retrieval  of  files 

-  Program  execution  (of  programs  stored  as  files) 

-  Use  of  special  peripherals  (e.q..  printers,  tape 
drives,  emulators,  etc.) 

Single  host  operating  systems  provide  a  uniform  interface  for 
accessing,  and  controls  for  mediating  access  to.  computer  system 
resources.  If  more  than  one  host  entity  (e.g..  program  or  user) 
can  access  and/or  use  a  given  resource  (e.g*.  tile,  printer, 
etc.),  that  resource  is  said  to  be  "shared".  Many  advantages 
accrue  from  resource  sharing,  including: 

-  Greater  utilization  through  multiplexing  (e.g.. 
printers) 

•  Reuse  without  duplication  (e.g*.  one  copy  of  a  compiler 
accessed  by  all  users) 

•  Communication  (e.g..  between  users) 

-  Lower  cost 

Similarly,  computer  network  can  make  (selected)  resources  of  all 
network  host  computers  available  to  the  network  (user)  community; 
i.e.  resource  sharing  can  occur  across,  as  well  as  within  the 
confines  of  host  computers. 

Now.  the  pioneering  nature  of  NSW  becomes  apparent.  NSN  has 
succeeded  in  achieving  a  uniformity  at  the  network  level  which 
had.  in  the  past,  only  been  accomplished  within  a  single-host 
environment.  To  achieve  uniformity  and  transparency  of 
operation,  nsm  provides: 

-  A  single  standard  command  language 

-  A  global,  distributed  file  system 

•  uniform  access  to  and  control  of  network  resources 
(i.e..  programs  called  "tools”  as  well  as  files) 


-  Integrated  project  management  facilities 
*  Centralized  accounting 

All  of  the  above  has  been  achieved  in  a  "heterogeneous" 
networking  environment  of  diverse  and  incompatible  host 
computers. 
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2.1  History 


Evolution  of  the  NSW  concept  and  development  of  the  NSW 
system  has  occurred  in  several*  sometimes  overlapping*  phases. 

The  five  (5)  phases  of  NSW  developaent  (31  are  orlefly  summarized 
below: 

1.  Feasibility  Demonstration  (July  1974  through  November 

1975) :  This  phase  included  formulation  of  the  oasic  ns w 
architecture*  ad  hoc  implementation  of  tne  malor 
software  "components”  (see  Section  4.4.1)  and 
demonstration  of  the  following: 

-  Use  of  IBM  360  batch  tools 

-  use  of  TENEX  interactive  tools 

•  Transparent  file  movement  and  translation*  and 

-  Rudimentary  project  management  capabilities 

2.  Detailed  Component  Design  (June  1975  through  March 

1976) :  During  tnls  period  external  and  functional 
specifications  were  completed  for  the  following  major 
components:  MSG  (the  NSW  interprocess  communication 
facility),  works  Manager*  Foreman  and  File  Pacxage.  A 
minimal  Front  End  (component)  specification  was  also 
prepared  during  this  period. 

3.  Prototype  implementation  (January  1976  through  November 

1977) :  This  phase  was  primarily  devoted  to 
implementation  of  NSW  components  for  varying  host 
environments.  During  this  period: 

•  TENEX*  IBM  and  Multlcs  MSG  implementations  were 
completed  and  demonstrated 

•  Initial  implementation  of  all  TENEX  components 
(Works  Manager*  Foreman  and  File  Pacxage)  were 
completed  and  demonstrated 

-  Implementation  of  the  Multlcs  Foreman  and  File 
Package  components  progressed  to  the  point  that  a 
"rudimentary  Multlcs  interactive  tool"  (4)  could  be 
demonstrated 

-  Development  of  the  IBM  Foreman  and  File  Pacxage 
components  was  started 


•  Preparation  of  tna  "interla  Reliability  Plan"  was 
Initiated 

4.  Reliability  and  Performance. Enhancement  (January*  1977 
through  Oeceaber  1980) t  This  phase  concentrated  on* 

-  Coapletlon  of  the  "Interla  Reliability  Plan*  and 
lapleaentatlon  of  specified  reliability  scenarios 

-  Addressing  perforaance  probleas  visible  m  the 
existing  (prlaarllv  TENEX/TOPS2-20)  component 
implementations  through! 

.  Development  of  perforaance  measurement  routines 
(completed  In  February  of  1978) 

•  instrumentation  of  all  (TENEX)  components  (completed 
In  may  of  1978) 

•  Coapletlon  of  the  Foreman  and  File  Package 
coaponents  for  the  IBM  and  Muitles  hosts* 

b.  Productization  (January  1979  through  April  1981):  The 
nsm  productization  phase*  covered  by  this  report*  is 
characterized  by  the  Introduction  and  Implementation  of 
a  plan  for  managing  the  development  and  operation  of  the 
nsn  system  (5).  This  plan  formalized  procedures  for: 

•  Release  integration  and  hand*off 

-  Quality  assurance 

•  software  Trouble  Reoort  (STR)  processing 

-  Configuration  management 

•  Production  operation 

*  This  phase  can  also  oe  characterized  as  a  period  of 
unprecedented  use  and  hardening  of  the  NSW  software* 

Many  probleas  and  deficiencies  In  the  areas  of 
operability*  reliability*  performance*  user/operator 
interfaces*  etc  were  successfully  eddressed*  (Thus*  the 
"Productization"  phase  is  also  considered  to  be  a 
continuation  of  Phase  4:  "Reliability  and  Perforaance 
Enhancement").  Also*  in  preparation  for  Phase  6 
("Technology  Demonstration  and  Transfer  Feesibillty")* 
much  of  the  planning  tor  the  AFLC  Technology 
Demonstration  was  completed  during  this  period*  During 
tne  next*  Technology  Demonstration*  phase  selected  AFLC 
sites  will  make  use  of  and  assess  NSW  and  networking 
technology  relative  to  current  and  future  AFLC  needs* 
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Phase  6  development  activities  will  oe  based  on  current 
planning  activities  aimed  at  determining  the  NSW 
features  and  performance  parameters  required  for  the 
planned  Technology  Demonstration. 
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2.2  Policy  Statements 

The  major  near-term  goals  of  the  NSW  project  are  summarized 
below  using  excerpts  from  policy  statements  Issued  durlnq  the 
contract  period  covered  by  this  report: 


Project  Evaluation  Policy  (November  24*  1979)  (6): 

-  "Our  immediate  goal  snouid  be  to  overcome  known 
performance  obstacles  and  rectify  known  design 
and  feature  deficiencies  to  provide  a  system 
capable  of  supporting  a  technology 
demonstration  within  the  APLC*  serve  as  a 
repository  and  testbed  for  JOVIAL  and  ADA 
programming  tools*  and  be  used  by  the  NSW 
development  community  and  by  selected  members 
of  the  ARPA  community." 

•  "The  Initial  task  should  be  a  reevaluation  of 
the  functional  performance  characteristics 
desired  in  the  system". 

•  "Our  performance  goal  should  be  to  provide  all 
of  the  critical  performance  characteristics 
required  by  the  above  postulated  user 
community*  and.  within  our  resource 
limitations*  those  desirable  characteristics 
which  will  enhance  user  satisfaction." 

-  "Our  Implementation  goal  should  be  to  have  any 
redeslqn/re-iapiementatlon  occur  as  a  series  of 
staged  releases  evolving  from  Release  4.1." 

Product  Policy  (November  24*  1979)  17): 

-  "in  general*  ...  proper  attention  snail  be 
given  to  operability*  (and)  maintainability*  in 
addition  to  functional  performance." 

•  "The  system  ultimately  provided  shall  permit 
tool  execution  which  epproximates  the  native 
environment  performance*  as  well  as  in  selected 
cases  provide  an  appropriate  execution 
environment." 

APLC  Demonstration  Policy  (November  24*  1979)  (8): 


IS 


•  "The  Intent  is  that  the  AFLC  Demonstration  have 
a  high  project  priority” 

-  "The  goal  is  to  demonstrate  selected  aspects  of 
NSW  functionality.  The  effort  Hill  be  executed 
in  three  phases*  the  first  two  of  which  provide 
introduction  to  networking  and  the  NSW*  and 
configure  the  necessary  tool  support  for  phase 
three.  During  the  third  phase*  the  functional 
demonstration  of  the  NSW  will  occur  using  a 
selected  AFLC  task." 

-  "The  demonstration  will  have  functionality  as 
its  goal  and  help  to  define  the  ultimate 
product  characteristics  for  the  AFLC 
application.” 

nsw  support  Strategy  (December  26*  1979)  (9]t 

•  "(A).  .  •  strategy  tor  the  use*  support  and 

modification  of  NSW  release  4.1"  reguesting 
coordinated  action  on  the  part  of  PDC  and  ACC 
(see  Section  3.1)  to: 

.  Develop  "a  plan  for  the  use  and  support 
of  the  current  release  4.1” 

.  Participate  "in  regularly  scneduled 

meetings  of  the  'working  group*  that  has 
been  set-up  to  coordinate  the  details  of 
the  AFLC  Technology  Demonstration.” 

•  Ensure  "a  smooth  transition  of  their 
(ACC  and  PDC)  Planning  activities”  to 
"assure  •  .  a  saootn  transition  from 

NSW  version  4.1” 
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3.0  NSW  Prolect  Organization 


During  the  prototyping  and  feasibility  demonstration  phases 
of  NSw  developaent  (prior  to  January  of  1979)  the  absence  of 
project  structure  and  discipline  had  been  the  note.  However#  the 
desire  to  harden#  ruggedlzed  and  enrich  (i.e.#  "productize")  the 
nsn  system#  coabined  with  tne  increasing  nuaber  of  geographically 
distributed  contractors#  established  the  need  for  formal  project 
management  discipline.  RADC  responded  to  this  need  by  preoarlna 
the  "NSW  Management  Plan"#  whlcnt 


1.  establishes  "...  an  overall  approach  for 
managing  the  development  and  operation  of  the 
National  Software  Worts  (NSW)"  (10)#  and 


2. 


Identifies  "responsibilities  of  participating 
organizations#  types  of  services  to  be  provided, 
and  directions  tor  future  growth"  (ll). 


3.1  Organizational  Structure 


The  roles  of  the  six  (6)  primary  nsw  organizational 
entities,  discussed  in  the  "NSW  Management  Plan",  are  summarized 
below: 

.  Policy  Group  (PG):  Largely  staffed  by  individuals  from 
the  sponsor  organizations  (RADC  and  ARPA),  PG 
responsibilities  include  resolution  of  "top  level  issues 
which  impact  nsw's  present  service  stance  and  future 
range  of  applicability"  (12).  Specific  PG 
responsibilities  include: 

•  Strategic  planning 

-  Resource  allocation,  and 

-  Organizational  conflict  resolution 

.  Architecture  Control  Contractor  (ACC):  ACC  is 
responsible  for: 

•  "Ensuring  (the)  continued  specif leationa>levei 
integrity  of  the  nsw  architecture*  (13) 

•  Interpreting  the  strategy  for  and  orchestrating 
the  development  of  NSw,  and 

-  integrating  the  various  software  components 
delivered  by  the  Development  Maintenance 
Contractors  (DMC's)  into  an  NSW  product  which  is 
both  operable  and  usable. 

.  Product  Development  Contractor  (PDC):  "Focusing  on 
those  steps  which  can  be  taken,  ...  to  bring  about 
near  term,  measurable  improvements  in  eitner  the 
feature,  performance  or  reliability  dbmalns"  (14),  PDC 
is  largely  responsible  for  "making  NSW  a  palpable, 
usable,  (and)  acceptable  product"  (15). 

•  nsw  system  Operations  (NSWOPS):  nswops'  role  is  to 
provide  the  nsw  user  community  with  "reliable, 
dependable  and  efficient  computational  services  and 
comprehensive,  correct  and  responsive  information 
services*  (16). 

•  Development/Malntenance  Contractors  (DMC's):  The 
individual  DMC*s  are  responsible  tor  implementation 
and/or  maintenance  of  one  or  more  NSW  software 
components  (see  Section  4.4.1).  OmC  activities  are 

IS 


directed  by  specifications  snd/or  guidelines  established 
and  aaintalned  by  ACC* 

Tool  Manager  (TM)s  The  nsm  Tool  Manager  is  responsible 
for  nanaglng  and  supporting  the  selection,  acquisition. 
Installation  and  maintenance  of  (nee)  NSW  tools  (see 
Section  6*1*3  for  a  discussion  of  NSW  tools). 


3.2  NSW  Contractors 


I 


’  J 


Summarized  oelow  are  the  sponsors  and/or  contractors  (and 
principal  contact)  responsible  for  each  of  the  NSW  organizational 
roles  discussed  in  Section  3.1: 

-  Policy  Croup  (PG) 

RADC/lSCP:  Dick  Metzger,  and  Ai  Barnum 

ARPA/IPTO:  Larry  Druffel 

-  Architecture  Control  Contractor  (ACC) 

.  Massachusetts  Computer  Associates  (COMPASS): 

Charley  Muntz 

-  Product  Development  Contractor  (PDC) 

General  Systems  Group*  Inc.:  Doug  Payne 

-  NSW  System  Operations  (NSMOPS) 

General  Systems  Group*  Inc,:  Doug  Payne 

-  NSW  Tool  manager  (TM) 

1IT  Research  institute  (1ITRI):  Loralne  Duval 

*  NSW  Development/Maintenance  Contractors  (DMCs) 

•  Massachusetts  Computer  Associates  (COMPASS): 

Charley  Muntz 

Bolt*  beranek  and  Newman*  Inc.  (BBN) :  Rick  Schantz 

(JCLA/Campus  Computing  Network  (CCN):  Nell  Ludlam 

Honeywell  Information  Systems  (HIS):  John  Ata 

•  Specific  component  responsibilities  o t  each  DMC  are 
detailed  in  Section  4.4.2. 

Although  no  formal  reporting  structure  has  been  established* 
Figure  3-1  (which  is  based  on  existing  protocols  and 
organizational  interactions)  provides  a  realistic'  approximation 
of  NSw *s  organizational  structure  (dashed  lines  indicate 
significant  organizational  interactions  which  span  the 
organizational  hierarchy). 
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4.0  NSw  System  Architecture 


The  (sub)sectlons  which  follow  present  a  "bottom-up" 
overview  ot  nsw  system  concepts  and  architecture.  Separate 
sections  are  devoted  to  the  following  topics: 


The  ARPA  Network 

NSW  host  families 

NSW  software  components 

Participation  of  hosts  in  NSW  systems  configuration 
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4.1  The  ARPANET 


NSW  has  been  implemented  in  the  ARPA  Network  (ARPANET) 
environment.  A  brief  description  of  tne  ARPANET  follows: 

•  "The  ARPANET  is  an  operational,  computerised,  packet 
switching  OoO  digital  network  which  provides  a 
capability  for  terminals  or  geographically  separated 
computers,  called  hosts,  to  communicate  with  each 
other.  The  host  computers  often  differ  from  one 
another  in  type,  speed,  word  length,  operating  system, 
and  other  characteristics.  Each  terminal  or  host 
computer  is  connected  into  the  network  through  a  small 
local  node  computer  called  an  IMP  or  TIP.  The  complete 
network  is  formed  by  interconnecting  the  Imps  through 
wideband  communication  lines  (normally  58,000  bits  per 
second)  supplied  by  common  carriers. 

Each  node  is  programmed  to  recieve  and  forward  messages 
to  neighboring  nodes  in  tne  network.  During  a  tyDlcal 
operation,  a  host  passes  a  message  to  its  node;  the 
message  is  passed  from  node  to  node  through  the  network 
until  it  finally  arrives  at  the  destination  imp,  which 
in  turn  oasses  it  along  to  the  destination  host.  This 
process  normally  takes  less  than  250  milliseconds. 

Hosts  communicate  with  each  other  via  regular  messages. 
A  regular  message  may  vary  in  length  from  96  to  8159 
bits,  the  first  96  of  which  are  control  bits  called  the 
leader.  The  leader  is  also  used  for  sending  control 
messages  between  tne  host  and  its  IMP  or  TIP  (node). 

The  remainder  of  the  message  is  tne  data  or  text. 

For  each  regular  message,  the  host  specifies  a 
destination,  consisting  of  node,  host,  and  handling 
type.  These  three  parameters  uniguely  specify  a 
connection  between  source  and  destination  hosts.  The 
handling  type  gives  the  connection  specific 
characteristics,  such  as  priority  or  non-prioritv 
transmission.  Additional  leader  space  has  been 
reserved  for  a  fourth  parameter,  to  be  used  in  future 
Internetwork  addressing.  For  each  connection,  messages 
are  delivered  to  the  destination  in  the  same  order  that 
they  were  transmitted  by  the  source. 

For  each  regular  message,  the  host  also  specifies  a 
12-bit  identifier,  the  message-ID.  The  message-lD, 
together  with  the  destination  of  the  message,  is  used 
as  tne  "name"  of  tne  message.  The  node  uses  this  name 
to  inform  the  host  of  the  disposition  of  the  message. 


Therefore,  if  the  host  retrains  fro*  re-using  e 
perticular  message-ID  value  (to  a  given  destination) 
until  the  node  has  responded  about  that  aessage-ID, 
messages  will  remain  uniquely  identified  and  the  host 
can  retransmit  them  in  the  event  of  a  failure  within 
the  network. 

After  receiving  a  regular  message  from  a  host  connected 
to  it,  a  node  breaks  the  message  into  several  packets 
(currently  the  maximum  data  bits  per  packet  is  1008) 
and  passes  these  through  the  network  in  the  direction 
of  the  destination,  eventually,  when  all  packets 
arrive  at  the  destination,  they  are  reassembled  to  form 
the  original  message  which  is  passed  to  the  destination 
host.  Tne  destination  node  returns  a  positive 
acknowledgement  for  receipt  of  the  message  to  the 
source  host.  This  acknowledgement  is  called  a  Ready 
for  Next  Message  (RFNM )  and  identifies  the  message 
being  acknowledged  bv  name.  In  some  relatively  rare 
cases,  however,  the  message  may  not  be  delivered  due  to 
a  node  failure,  line  disruption,  etc.,  in  such  cases  an 
Incomplete  Transmission  message  win  be  returned  to  the 
source  host  instead  of  a  RFNM.  In  this  case  tne 
message  which  was  incompletely  transmitted  is  also 
Identified  by  name. 

if  a  response  from  the  destination  node  (either  RFNM  or 
incomplete  Transmission)  is  not  delivered  to  the 
originating  host,  this  condition  will  be  detected  by 
the  source  node,  which  will  automatically  inquire  of 
the  destination  node  whether  the  original  message  was 
correctly  received  and  repeat  the  inquiry  until  a 
response  is  received  from  tne  destination  node.  This 
inquiry  mechanism  is  timeout-driven,  and  each  timeout 
period  may  vary  between  39  and  45  seconds  in  length. 

Nhen  a  message  arrives  at  its  destination  node,  the 
leader  is  modified  to  Indicate  the  source  host,  but  the 
message-lD  field  is  passed  through  unchanged.  Thus,  in 
addition  to  providing  message  identlf icetlon  between  a 
host  and  its  local  node,  the  message-10  can  provide  a 
means  for  hosts  to  identify  messages  between 
tnemseives. 

Users  of  the  ARPANET  may  access  local  or  distant  server 
computer  (hosts)  over  the  network.  They  may  also 
exchange  messages,  create  realtime  links  between  users, 
transfer  files  from  one  computer  to  another,  and  submit 
batch  loos  to  distant  computers.  For  a  more  complete 
description  of  these  processes,  see  the  ARPANET 
Protocol  Handbook  available  from  tne  (Network 
information  Center)  NIC  or  tne  National  Technical 


Information  System  (NTIS),  Springfield,  VA.  22161  as 
AD  A052594 • "  117] 

The  ARPANET  communications  subsystem  configuration  (l.e.,  imp* 
and  TIPs  ••  see  above)  is  shown  in  Figure  4-1  118];  Figure  4-2  is 
an  Arpanet  schematic  which  includes  host  identifiers  1191. 


4.2  NSW 


A  Network  Operating  System 


The  National  software  works  (NSw.)  is  an  operating  system. 
Because  it  has  been  implemented  in  a  networking  environment,  nsw 
is  often  called  a  "network  operating  system".  Much  like  a  single 
host  operating  system,  nsw  manages  network  resources,  providing 
its  users  with  uniform  access  to  files.  Programs  (called  "tools") 
and  hardware  resources  available  from  network  nosts  which 
"participate"  in  the  NSW  system.  However,  the  nsw  network 
operating  system  differs  from  single-host  operating  systems  in 
many  significant  and  important  ways: 

-  nsw  operates  in  the  networking  environment,  where 
interactions  between  two  or  more  geographically 
dispersed  computers  may  oe  reguired  to  complete  a 
user's  request. 

-  nsw  is  an  operating  system  which,  itself,  has  been 
built  "on  top"  of  existing  single  host  operating 
systems. 

-  nsw  has  been  built  to  operate  on  a  set  of  DISSIMILAR 
computer  systems,  and  to  provide  users  with  uniform, 
controlled  access  to  the  resources  of  these 
dissimilar  computer  systems. 
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4.3  Host  Pantiles 

NSW  software  components  (see  Section  4.4.1)  aust  be 
implemented  for  an  Arpanet  host  computer  system  in  order  for  that 
nost  to  "participate”  In  a  configuration  of  the  NSW  network 
operating  system.  Generally  speaking,  the  level  at  which  a  host 
can  participate  in  an  NSW  configuration  Is  determined  by  the 
number  of  different  NSW  software  components  implemented  for  that 
host.  Since  the  operability  of  NSW  component  Implementations  is 
largely  Independent  of  hardware  configuration  and/or  operating 
system  version/release,  we  often  speak  of  "host  families"  when 
referring  to  ns*  component  implementations.  That  is.  NSW 
software  components  may  oe  implemented  once,  for  a  "host  family", 
then  the  software  components  can  be  installed  on  each  host  (of 
that  family)  participating  in  the  NSW  system  configuration. 

The  nsw  host  families  and  the  current  set  of  constituent 
ARPANET  hosts  (i.e..  participating  family  members)  are  itemized 
below: 


-  TENEX/TOPS-20 

IS1E;  DECSystem-20  (1099T)  running  TOPS-20 
version  3A. 

IS1C:  DECSystem-20  (KA10)  running  TOP6-20  version 
3A. 

RADC-29:  DECSystem-20  (2040T)  running  TOPS-29 
version  4. 


-  1BM/0S 

UCLA-CCN:  3033  runnlnq  MVS  (Note:  CCN  is 

currently  converting  from  0S/VS1  to 
MVS) 

-  MultlCS 

RADC-Mul tics :  H6180  running  Multlcs 

-  Unix 

radc-unixi  PDP-ll/45  running  Unix  (future  Front 
End  Host  —  see  Section  4.4.3) 

ROBINS-UNIX:  PDP-ll/45  running  Unix  (future 
Front  End  Host  —  see  section 
4.4.3) 
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4.4  NSW  Software  Architecture 

The  nsw  functionality  has  been  logically  decomposed  and 
grouped  into  a  set  of  software  "components”.  Host-independent 
specifications  exist  for  each  malor  NSW  component.  These 
specifications  are  used  as  the  basis  for  realizing  component 
Implementations  for  different  host  families. 

nsw  components  communicate  with  one  another  through  an 
interprocess  communication  facility  called  msg  (Figure  4-3). 
msg.  combined  with  existing  Arpanet  "protocols”*  serves  as  the 
foundation  for  implementing  higher  level*  NSW  protocols. 

Protocol  interactions  between  components  are  often  grouped  into 
"nsw  scenarios";  each  NSw  scenario  reliably  implements  one  (or 
more)  NSW  operating  system  function(s). 

For  an  ARPANET  host  to  "participate”  in  an  nsw  system 
configuration*  host  (family)  implementations  of  the  interprocess 
communication  facility  (MSG)  and  at  least  one  other  NSn  component 
must  exist.  The  level  at  which  a  host  (family)  can  participate 
in  an  NSW  system  is  constrained  by  the  set  of  NSw  components 
Implemented  tor  that  host  (family).  NSW  software  components  (see 
section  4.4.D  are  each  associated  with  a  set  of  nsw  operating 
system  services.  The  level  at  which  a  particular  network  host 
participates  in  NSw  system  configuration  is  determined  by  the  set 
of  implemented  services  (executing  components)  the  host  provides 
tor  the  NSW  user  community. 

An  nsw  system  "configuration"  consists  of  a  set  of  ARPANET 
hosts  participating  at  various  levels  according  to  the  nsw 
operating  system  services  they  provide  (operating  system  services 
are  implemented  by  the  NSW  software  components  -  see  above).  An 
ARPANET  host  may  participate  in  more  than  one  NSW  system 
configuration. 

nsw  resource  management  and  control*  including 
authentication*  access  control*  synchronization  and  accounting 
are  logically  centralized  in  a  set  of  "core  system”  software 
components.  The  "core  system"  components  run  on  the  "core  system 
host”;  there  is  one  "core  system  nost"  per  nsw  system 
configuration.  Thus*  the  "core  system  host”  enlovs  the  highest 
level  of  participation  in  an  NSw  system  configuration.  Non-"core 
system”  components*  run  primarily  on  non-"core  system"  network 
hosts  out  may  (and  freguently  do)  run  on  the  "core  system  host" 
as  well.  A  single  "core  system”  host  means  that  the  cost  tor 
other  non-”core  system”  hosts  to  participate  in  an  NSW  system 
configuration  (in  terms  of  system  resources)  is  relatively  low. 
That  is*  only  the  "core  system  host”  pays  the  price  to  provide 
the  expensive  "core  system"  services  mentioned  aoove. 


A  central  set  of  "core  system"  components  also  means  that 
NSW  logically  takes  the  shape  of  a  "star*  (Figure  4*4).  This 
star-like  control  structure  does  not  preclude  direct 
communication  between  non-"core  systea"  components  (as  indicated 
by  the  dashed  lines  of  Figure  4-4).  However,  such  interactions 
are  usually  coordinated  in  advance  with  the  "core  system". 


ARPANET 


s  Star  Shaped  Control  Structure 


Figur«  4-4 


4.4.1  NSw  Software  Components 


Logically  speaking,  the  NSW  system  consists  of  eleven  (11) 
functional  software  packages  called  "components”.  These 
components  consist  of  generic  (i.e..  implementation  independent) 
groups  of  NSW  functionality  which  may  be  realized  for  one  or  more 
of  the  nsw  host  families  (by  nsw  Oevelopnent/Maintenance 
Contractors  (DMC's)  —  see  Section  3.1).  A  brief  description  of 
each  generic  nsw  component  is  given  below: 

•  msC:  The  Interprocess  communication  facility  used 

by  all  components  to  communicate  with  and  request 

services  of  one  another  is  called  MSG. 

-  "Core  System"  Components: 

.  works  Manager  (wm):  The  works  Manager  is  nsw*s 
system  resource  manager  and  control  point, 
providing  centralized  authentication,  access 
control,  synchronization,  and  accounting.  The 
works  Manager  maintains  several  critical 
databases,  including: 

-  a  central  file  catalog 

-  A  central  tool  (executable  program)  catalog 

-  Project  organizations  (see  Section  6.1.1) 

*  User  ids.  passwords,  and  rights 

•  Checkpolnter  (CHKPTR):  The  Checkpointer 
maintains  works  Manager  database  integrity 
through  periodic  back-up. 

•  works  Manager  Operator  (wmo):  The  wwo  directs 
and  coordinates  the  execution  of  "batch  jobs" 
with  non-"core  system"  Batch  Job  Package 
components  (see  below). 

•  Fault  Logger  (FL):  The  Fault  Logger  is  the 
central  operator-visible  collection  point  for 
"faults”  (abnormal  and/or  error  conditions) 
reported  by  other  NSw  components. 

.  Operator  Utility  (OPRUTL):  OPRUTL  is  one  of  many 
operator  utilities;  it  provides  nsw  operators 
with  a  number  of  high-level  "core  system" 
component  manipulation  and  clean-uo  ope.  it ions. 
OPRUTL  has  been  elevated  to  component  status 


because  some  operator  functions  communicate  with 
the  "core  system"  components  though  MSG. 

Non-"Core  system"  Components" 

Foreman  (FM):  The  Foreman  component  oversees  the 
execution  ot  interactive  tools  (executable 
programs).  One  important  function  of  the  Foreman 
is  to  Intercept  operating  system  calls  (e.g., 
tile  references)  and  direct  them  to  NSW  or  the 
local  operating  system,  as  appropriate. 

File  Pacxage  (FLPKG)s  The  File  Package  component 
manages  a  host-resident  portion  of  nsw  tllespace. 
File  Packages  resident  on  different  NSW  host6 
Interact  with  each  otner  to  transfer  files 
between  different  (host-resident)  portions  of  nsw 
tile  space.  The  File  Package  is  also  responsible 
for  translating  tiles  as  they  are  moved  between 
hosts  which  belong  to  different  host  families. 

Batch  Job  Package  (BJP)i  Under  direction  ot  the 
works  Manager  Operator  the  Batch  Job  Package  maps 
user-initiated  "batch  lobs”  into1  the  local  host 
execution  environment  and  oversees  their 
execution. 

Front  End  (FE):  The  nsw  Front  End  implements  and 
interprets  the  nsw  command  language.  Alternative 
Front  End  implementations  may  realize 
syntactically  and  semantically  different  command 
languages  (see,  for  example.  Section  6.2.1).  A 
request  initiated  by  the  Front  End  always  begins 
an  nsw  "scenario",  involving  interactions  with  at 
least  one  other  NSW  component.  Based  on 
user-supplied  commands  and  parameters,  the  Front 
End  requests  services  implemented  by  other  NSW 
components  (usually  the  "core  system”  works 
Manager )  • 

Dispatcher  (DSPCHR):  Contacting  a  standard  host 
socket  causes  the  Dispatcher  to  place  the 
(prospective)  NSW  user  In  contact  with  a  spawned 
Front  End  Instance. 


4.4.2  DMC  Responsibilities 

Tne  four  (4)  nsw  component  Development/Maintenance 
Contractors  (see  Section  3.2)  are. each  responsible  for  several 
host  family  component  implementations.  These  responsibilities 
are  summarized  below  by  host  family. 

TOPS-20 

MSG  -  BBN 

"Core  System”  Components: 

•  works  Manager  *  COMPASS 

-  Checkpointer  -  COMPASS 

•  works  Manager  Operator  -  COMPASS 

-  Fault  Logger  •  bbn 

-  operator  utility  -  compass 
Non-"Core  system"  Components: 

-  Foreman  -  BBN 

-  File  Package  -  COMPASS 

-  Front  End  -  COMPASS 

-  Dispatcher  -  BBN 

IBM 

MSG  -  UCLA/CCN 

"Core  System"  Components: 

**  none  ♦* 

Non-"Core  System”  Components: 

-  Foreman  -  UCLA/CCN 

-  File  Package  -  UCLA/CCN 
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•  Batch  Job  Package  -  UCLA/CCN 

Multies 

MSG  -  HIS 

"Core  System"  Components: 

**  none  ** 

Non*"Core  System"  Components: 

-  Foreman  -  HIS 

•  File  Package  -  His 

Unix 

MSG  -  BBN 

"Core  System"  Components: 

**  none  ** 

Non«"Core  System"  Components: 

-  Front  End  -  BBN 
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4.4.3  Participation  of  Hosts  in  nsw  Configurations 

The  level  at  wnicn  an  ARPANET  host  way  participate  in  an  NSW 
system  configuration  is  determined  by  tne  collection  of  software 
components  implemented  for  the  associated  host  family.  (Note: 

An  implementation  of  MSS  is  required  for  any  level  of 
participation.)  The  five  (5)  disjoint  levels  at  which  a  host  may 
participate  in  an  NSW  configuration  (or.  alternatively  the  five 
sets  of  operating  services  a  host  may  offer  by  participating  in 
an  nsw  system  configuration)  are  each  described  below: 

-  Core  System  Host  (CSH):  only  one  host  per  nsw 

configuration  can  serve  as  tne  "core-system  host"  by 
providing  tne  following  NSW  functions:  authentication, 
access  control,  synchronization  and  accounting.  Host 
family  implementations  of  the  following  "core  system" 
components  are  required: 

wortcs  Manager 

Checkpolnter 

•  works  Manager  Operator  (required  only  if  the  nsw 
configuration  Includes  one  or  more  Batch  Job  Package 
components). 

.  Fault  Logger  (required  only  if  tne  nsw  configuration 
includes  one  or  more  components  wnicn  report 
"faults”  to  the  Fault  Logger). 

.  Operator  utility  (as  required  by  nost  family 
implementations  of  the  works  Manager  and 
Checkpolnter ). 

•  File  Bearing  Host  (FBH):  Any  nost  tor  wnicn  a  (host 
family)  implementation  of  tne  File  Package  component 
exists  can  oversee  a  portion  of  nsw  fllespace  resident 
on  that  nost  by  providing  support  for: 

•  File  transfer  and  translation  between  host-resident 
portions  of  NSW  fllespace 

.  Tne  movement  of  tiles  between  NSW  fllespace  and  the 
local  nost  file  system. 

•  The  Datacomputer  (now  defunct)  is  an  example  of  an 

Arpanet  nost  which  might  wish  to  participate  in  an  nsw 

system  configuration  only  as  a  File  Bearing  Host  (i.e.. 

not  as  a  Tool  Bearing  Host  —  see  below). 
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(Interactive)  Tool  Bearing  Host  (TBH):  Any  host  for 
which  a  host  family  implementation  of  the  Foreman 
component  exists  can  provide  support  for  the  execution 
of  interactive  "tools"  (executable  programs).  However, 
the  Foreman  cannot,  without  a  File  Package  coaponent, 
support  tools  which  reference  NSW  files.  Thus, 
participation  as  a  File  Bearing  Host  is  almost  always 
considered  a  prerequisite  to  participation  as  a  Tool 
Bearing  Host. 

Batch  Job  Host  (BJH) :  Any  host  for  which  a  host  family 
implementation  of  the  Batch  Job  Package  component 
exists  can  participate  in  an  NSW  system  configuration 
as  the  executor  of  NSW  batch  job  processing  on  that 
host.  Of  course,  such  participation  assumes  a  "core 
system”  configuration  which  Includes  a  works  Manager 
Operator  component  (see  above).  Also,  because  certain 
information  required  for  batch  processing  is 
transmitted  from  the  works  Manager  Operator  to  the 
Batch  Job  Package  through  the  nsw  file  system,  support 
tor  nsw  files  (l.e.,  a  host-resident  File  Package 
component)  is  also  required. 

Front  end  Host  (FEH) :  A  Front  End  Host  acts  as  a  user 
access  point  for  an  nsw  system  configuration.  Any  host 
for  which  a  host  family  implementation  of  the  Front  End 
component  exists  can  be  an  NSW  access  point  providing 
user  interface  (l.e.,  nsw  command  language)  support. 


39 


4.4.4  Levels  ot  Host  Family  Participation 


usinq  the  "levels  of  participation"  discussed  in  Section 
4.4.3.  we  can  summarize  the  levels  of  participation  possible  for 
each  NSW  host  family  identified  in  Section  4.3: 

.  TOPS-20  (tops-20  host  can  participate  in  an  NSW 
configuration  as  one  or  more  ot  the  following): 

-  Core  System  Host  (CSH) 

•  File  Bearing  Host  (FBH) 

•  Tool  Bearing  Host  ( TBH ) 

-  Front  End  Host  (FEH) 


IBM: 

•  File  Bearing  Host  (FBH) 

-  Tool  Bearing  Host  (TBH) 

-  Batch  job  Host  (BJH ) 
Multics: 

-  File  Bearing  Host  (FBH) 

•  Tool  Bearing  Host  (TBH) 


Unix: 


•  Front  End  Host  (FEH) 

One  or  more  "levels  of  participation”  have  been  assigned  to 
each  host  family  listed  above.  An  ARPANET  nost  which  belongs  to 
(i.e.,  is  compatible  with)  one  of  the  nsw  host  families  CAN 
participate  at  any  of  tne  levels  listed  above  for  that  family. 
For  example,  any  ARPANET  DECSystem-20  running  TOPS-20  can 
participate  in  an  NSW  system  configuration  as  a: 

•  Core  System  Host  (CSH) 

•  File  Bearing  Host  (FBH) 

-  Tool  Bearing  Host  (TBH) 
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Front  End  Host  (FEH) 


or  any  combination  of  tne  above,  me  RADC-20  ARPANET  host#  a 
DECSystem-20  running  TOPS-20,  provides  a  specific  example. 
Currently  tne  RADC-20  participates  in  several  NSw  configurations. 
In  the  NSw  user  System  configuration  (sea  Sections  4,4,5  and 
5,1),  the  rauC-20  participates  as  a  Tool  Bearing  Host  and  a  File 
Bearing  Host*  but  not  as  a  Core  System  Host  or  a  Front  End  Host. 


4.4.5  NSW  user  System  Configuration 

The  production  NSW  configuration  available  to  nsw  users  is 
called  the  "NSW  User  System".  The  User  System  configuration 
(Figure  4-5)  consists  of  ARPANET  hosts  participating  at  various 
levels  (see  Section  4.4.3).  The  level(s)  of  host  participation 
In  the  User  System  configuration  are  summarized  Delow  (by  ARPANET 
host) : 


USC/1S1E  (TOPS-28) 

-  Core  System  Host 

*  Tool  (and  File)  Bearing  Host 

-  Front  End  Host 

USC/1S1C  (TOPS-28) 

*  Tool  (and  File)  Bearing  Host 

-  Front  End  Host 

RADC-20  (TOPS-28) 

-  Tool  (and  File)  Bearing  Host 
ucbA-cCN  (soon  to  be  running  mvs) 

-  Tool  (and  File)  Bearing  Host 

-  batch  Job  Host 

RADC-MUbTICS 

*  Tool  (and  File)  Bearing  Host 
Note  the  following: 

*  USC-ISIE  is  tne  only  core  system  host  in  the  User 
System  configuration. 

*  RADC-20  could  be*  but  is  not*  a  Front  End  Host  (even 
though  a  Front  End  component  implementation  exists  for 
tne  TOPS-20  host  family). 

*  ucla-ccn  is  the  only  Batch  Job  Host  (tne  IBM  host 
family  is  tne  only  family  for  which  a  Batch  Job  Package 
has  been  implemented). 
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*  UCLA/CCN  and  RADC-HULTICS  could  not  be  Front  end  Meet* 
(Front  end  coaponents  have  not  been  lapleaented  tor 
either  tne  IBM  or  nuitlcs  noat  taailiet). 

•  Tne  User  system  configuration  includes  no  Unix  hosts 
(tne  Unix  Front  End  nas  not  yet  been  released  for 
integration  into  the  user  System  configuration). 
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5.0  nsw  System  Development 


At  tne  highest  level,  NSW  system  development  can  oe  viewed 
as  a  sequence  ot  stages,  each  of  which  is  performed  and 
controlled  by  a  different  NSW  organization.  Tne  four  (4)  stages 
of  the  NSW  system  development  life  cycle  are  briefly  described 
below  (see  Figure  5-1): 

1.  Component  Development  and  Maintenance:  The  nsw 
Development/Maintenence  Contractors  (DMC's  —  see 
Section  3.1)  are  responsible  for  developing  and 
maintaining  host  family  implementations  of  specific 
nsw  software  components,  when  a  new  component 
version  is  considered  ready  tor  release,  the 
responsible  DMC  delivers  it  to  the  NSW  Architecture 
Control  Contractor  (ACC)  for  integration. 

2.  System  integration:  It  is  ACC's  lob  to  integrate 
components  received  from  the  various  DMC's  into  an 
operable  nsw  system  and  to  verify  that  the  components 
interact  properly  with  one  enotner.  The  DMC's  work 
with  ACC  to  isolate  and  correct  problems:  components 
which  do  not  "pass  muster"  are  returned  to  the 
appropriate  dmc  for  additional  work,  since  the  dmc's 
operate  esyncnronously  from  one  another,  nsw  system 
integration  is,  defacto,  an  incremental  process. 

That  is,  at  most  a  tew  components  are  introduced  into 
a  staoie  NSw  system  conf lguretlon  at  a  time. 

However,  incremental  integration  has  tne  advantage  of 
making  ACC's  integration  testing  (and  problem 
isolation)  task  somewhat  easier,  when  ACC  is 
confident  that  the  integrated  NSw  system  is  ready  for 
production  operation,  its  constituent  components  are 
packaged  into  a  system  releese  which  is  then 
delivered  to  tne  NSw  product  Development  Contrector 
(PUC)  for  Quality  Assurance. 

3.  Quality  Assurance  (Q/A):  It  is  PDC's  tmsk  to  verity, 
through  independent  testing,  that  NSW  system  releases 
are  ready  for 

-  Production  operation  by  nsw  System  Operations 
(NSwOPS),  and 

-  use  oy  the  nsw  user  community* 

.  Upon  completion  ot  u/A,  PDC  provides  the  NSW  Policy 
Croup  (PC)  with  recommendations  regarding  production 
operation  of  the  release,  including  any  corrective 
ectlon  which  mey  be  required  to  make  tne  release 
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operable/usabie.  Based  on  recommendations  from  PDC  as 
«eil  as  Input  from  ACC ,  and  NSwOPS,  PG  makes  one  of  two 
determinations: 

-  Return  tne  release  to  ACC  (and  the  one's) 
for  further  work,  or 

-  Deliver  the  release  to  NSWOPS  tor 
Installation  and  production  operation. 

4.  installation  and  Production  Operation:  NSWOPS 

operates  the  national  NSW  user  system  configuration 
on  penalf  of  the  NSW  user  community.  When  a  new 
release  (or  notification  thereof)  is  received  from 
PDC,  NSWOPS: 

•  Schedules  an  installation  date 

-  broadcasts  a  summary  of  the  release  (including 
release  date)  to  the  NSW  user  community,  and 

-  (On  the  designated  data)  Installs  and  begins 
operation  of  the  new  release. 

Note  (see  figure  5-1)  that  each  stage  of  the  NSW  system 
development  process  provides  a  feedback  loop  to  the  immediately 
preceding  stage,  in  this  way,  user  and  operator  experiences  in 
the  form  of  bugs,  deficiencies  and/or  desired  features  may  be 
communicated  to  PDC,  ACC  and  ultimately  the  DMC's  for  analysis, 
prioritization  and  action. 


components (si  component (s) /system (s) 


5*1  nsw  system  Configurations 

To  maximize  efficiency#  it  lust  be  possible  for  each  step  of 
the  nsw  system  development  process  to  proceed  independently  of 
all  otners.  in  particular#  it  must  be  possible  for: 

•  nswops  to  operate  the  current  release  while  new 
releases  are  at  various  staqes  of  development. 

•  PDC  to  perform  Q/A  on  a  new  release  (n+i)  while  ACC  is 
Integrating  a  future  release  (n+2>  and  NSWOPS  is 
operating  the  currently  installed  release  (n). 

•  ACC  to  integrate  a  release  (n+1)  while  PDC  is 
performing  Q/A  on  a  recent  release  (n)  and  DNC's  are 
preparing  components  for  future  integration  (release 
n+1  or  greater). 

-  Dmc's  to  prepare  new  component  version(s)  Independent 
of  ACC  integration  activities. 

Four  (4)  distinct  nsw  system  configurations  were  established 
to  provide  the  necessary  organizational  autonomy  which  would 
allow  each  step  of  NS*  system  development  to  proceed 
Independently  of  all  others  (Figure  5»2)r 

1.  The  nsw  "Debug"  System  configuration#  controlled  by 
ACC#  is  used  by  the  DMC’s  to  prepare  new  component 
versions. 

2.  The  nsw  "Development"  System  configuration  is 
controlled#  operated#  and  used  by  ACC  to  integrate 
components  into  system  releases  which  can  then  be 
delivered  to  PDC  tor  o/A. 

3.  The  nsw  "Candidate"  System  configuration#  operated  by 
nswops#  is  controlled  and  used  by  PDC  for  Q/A. 

4.  The  nsw  "User"  System  configuration  is  controlled  and 
operated  by  NSWOPS  on  behalf  of  the  NSw  user 
community. 
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5.2  NSW  Testing  Hierarchy 

NSW  System  software  is  separately  tested  during  each  stage 
of  the  system  development  process  (see  Section  5.0).  Tests  for  a 
given  stage  are  most  often  applied  to  one  or  more  nsw  components 
which  have  peen  installed  in  the  associated  NSw  system 
configuration  (see  Section  5.1).  Devised  and  applied  tests  are 
oriented  toward  the  system  development  activities  of  each  stage 
(e.g..  0/A)  and  reflect  progress  along  the  development  continuum 
leading  to  production  operation  of  new  NSw  system  releases. 
Collectively,  tests  applied  during  development  stages  one  (1) 
through  four  (4)  form  a  hierarchy  in  wnicn  individual  components 
are  tested  first  (this  is  called  "unit"  testing),  then  individual 
components  are  integrated  into  a  full  NSW  system  configuration, 
which  receives  two  separate  batteries  of  tests:  integration  and 
Q/A.  The  testing  activities  associated  with  each  stage  of  the 
nSw  system  development  process  are  summarized  below: 

1.  Unit  Testing:  fcach  NSW  software  component 
implementation  is  referred  to  as  a  unit.  These  tests 
are  (often)  applied  to  components  installed  in  the 
NSW  Debug  System  configuration.  Unit  tests  are 
devised  and  applied  by  the  DMC  with  implementation 
responsibility  to: 

•  Components  in  isolation  to  verify  correct 
operation  of  Internal  functions,  and/or 

•  Small  collections  of  components  to  verity  that 
the  component  interacts  properly  with  other  nsw 
components. 

•  Components  which  have  "passed”  unit  testing  are 
delivered  to  ACC  for  integration. 

2.  Integration  testing:  it  is  ACC's  responsibility  to: 

-  Integrate  nsw  components  received  from  Due's 
into  an  operational  NSW  system. 

•  verify  the  system,  specification  and 
inter-component  integrity  of  complete  component 
configurations  (i.e..  full  nsw  system 
configurations),  and 

-  Package  and  deliver  nsw  releases  to  PDC  for  0/A 

•  Integration  tests  are  devised  and  applied  to  components 
(receiv  .*  from  the  DMC's)  wnicn  have  been  installed  in 
the  nsw  Development  System.  Due  to  the  asynchronous 
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nature  of  conponent  deliveries  fro*  the  dmc’s#  nsw 
system  integration  is  largely  an  incremental  process. 
However#  Incremental  integration  does  nave  its 
advantages:  if  the  installation  of  new  components  in 
tne  Development  System  can  oe  spaced  (in  time) 
sufficiently  apart  from  one  anotner#  tne  job  of 
isolating  problems  (when  they  do  occur)  becomes 
significantly  easier.  ACC  has#  for  this  reason# 
adopted  the  incremental  integration  and  testing 
approach.  Incremental  integration  does  require 
continuous  operation  and  support  of  the  NSW  Development 
System  which  has  the  additional  advantage  of  providing 
NSW  developers  (DMC's)  with  access  to  a 
fully-integrated,  operational  NSW  system  prior  to  O/A 
and  release  tor  production  operation,  wnen  the 
integration  process  nas  been  completed#  ACC  packaqes 
the  current  set  of  components#  databases  and 
documentation  for  delivery  to  PDC  who  will  perform  Q/A. 

3.  Quality  Assurance  (Q/A)  Testinq:  PDC  is  responsible 
for  independent  validation  and  verification  of  tne 
new  NSW  systems  released  to  ACC.  During  the  0/A 
testing#  NSW  systems  delivered  by  ACC  are  installed 
and  operated  by  NSWOPS  in  the  NSW  Candidate  System 
configuration.  PDC  prepares  and  applies  independent 
system-level  tests  to  each  major  new  ns*  system 
release.  The  results  of  these  tests  are  communicated 
to  the  development  community  (ACC)  and#  along  with 
recommendations  for  action#  to  PG  for  determination 
of  release  disposition,  (A  more  detailed  discussion 
of  GSG’s  quality  assurance  may  be  found  in  Section 
5.4.) 


4.  Production  Operation:  NSWOPS  installs  and  operates 
new  nsw  system  releases  for  the  NSW  user  community  in 
the  nsw  user  System  configuration;  these  releases  are 
delivered  to  NSWOPS  by  PDC  (as  directed  by  PG).  In 
addition#  NSWOPS  is  responsible  tor  tne  timely 
resolution  of  user  questions  and  problems  (sometimes 
called  Software  Trouble  Reports  (STRs)  —  see  Section 
5.5).  Thus#  NSWOPS  must  view  and  review  the  NSW 
syste...  from  both  the  operational  and  user 
perspectives.  To  provide  an  NSW  system  which  is 
maximally  operable  and  trouble-free,  the  testing 
efforts  of  stages  one  (l)  through  three  (3)  of  the 
system  development  process  concentrate  on  removing  as 
many  (major)  problems  and  deficiencies  as  possible. 
Loosely  speaking#  tne  testing  an  NSW  system  receives 
during  production  operation  is  "use”#  which  is 
undoubtally  the  most  important  kind  of  testing  and  an 
important  source  of  feedback  tor  PDC#  ACC  and  the 
DMC’s  as  well.  User  (and  operator)  acceptability  is 
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the  ultimate  test.  (For  e  detailed  discussion  of 
GSG*s  system  operation  responsibilities  and 
activities  see  Section  7.0.) 


i 


5*3  NS*  System  Release  and  Assessment  Procedure 


When  system  Integration  (and  testing)  has  been  completed, 

ACC  Dackaqes  and  delivers  tne  new  nsw  system  to  PDC  for  Quality 
Assurance  (Q/A).  Due  to  tne  autonomous  operational  requirements 
ot  the  IBM  and  Multics  NSW  hosts,  this  DELI  VERY  takes  the 
following  form  organizationally: 

ACC:  Delivers  all  T0PS-2B  components  to  PDC/NSWOPS 

nSwops:  installs  and  operates  NSW  TOPS-2®  component 
configurations  (Including  the  "core  system" 
components  —  see  Section  4.4)  on  the  USC-lSIE, 
USC-1S1C  and  RADC-20  hosts 

DMC“CCN :  installs  and  operates  an  NSW  IBM  component 
configuration  on  tht  UCLA-CCN  host 

Dmc-his:  installs  and  operates  an  NSw  Multics 

component  configuration  on  the  RADC-Muitlcs 
host. 

when  a  new  system  has  been  delivered  for  Q/A  by  ACC,  a 
release  assessment  and  transition  procedure  developed  by  PDC  (and 
ACC)  takes  effect.  This  procedure  covers  the  last  two  stages  of 
the  NSW  system  development  process: 

Stage  3:  Quality  Assurance  by  PDC 

Stage  4:  Production  Operation  oy  NSWOPS 

As  contractor  for  botn  the  POC  and  NSWOPS  organizations,  CSC 
is  responsible  for  these  two  stages  of  the  NSW  system  development 
process.  Note  that  the  procedure  outlined  below  is  presented 
from  tne  pdc/nswops  perspective  (i.e.*  that  of  POC  receiving 
releases  tor  Q/A  from  ACC  and  that  of  nswops  receiving  releases 
from  PDC  for  production  operation).  The  steps  ot  the  NSW  system 
release  and  assessment  procedure  are: 

1.  ACC:  Integrate  nsw  components  received  from  the 
dmc * s  into  an  operational  nsw  system:  perform 
integration  testing. 

2.  ACC:  when  system  integration  has  been  completed: 

•  Identity  and  obtain  specific  versions  for  each 
"generic  configuration  item"  (see  Section  5.6 
and  Appendix  C)  ot  tne  new  NSW  system,  and 
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•  Deliver  the  NSW  System  end  IOPS-28  Host  Family 
"packets"  (of  configuration  items  -  see  Section 
5.6)  to  PDC/NSWOPS. 

3.  NSNOPS:  install  selected  configuration  items  iron 
the  "NSW  System"  and  TOPS-28  "Host  Family"  packets  in 
the  NSW  Candidate  System  configuration;  coordinate 
installation  of  the  IBM  Host  Fasily  and  Multics  Host 
Fanily  packets  with  DMC-CCN  and  DNC-HIS  respectively. 

4.  ACC:  Verify  that  the  new  NSW  systea  nas  been 
installed  properly  in  the  NSW  Candidate  Systea 
configuration;  coordinate  verification  activities 
witn  DMC-CCN  and  DMC-H1S 

5.  nswops:  Operate  the  new  NSw  systea  in  the  NSW 
Candidate  Systea  configuration  (including  the  "core 
systea”)  for  PDC  during  Quality  Assurance;  direct  and 
coordinate  operational  activities  witn  DMC-CCN  and 
0MC-H1S. 

6.  PDC:  Direct  tne  application  of  quality  assurance 
tests  to  tne  new  NSW  systea  release  (see  Section  5.4 
tor  details);  report  results  and  release 
recommendations  to  PG  and  ACC. 

7.  PG:  Based  on  Q/A  test  results  and  input  from  PDC, 
nswops  and  ACC,  select  one  of  the  following  courses 
of  action: 

a.  Return  the  release  to  ACC  for  malor  modification 
(i.e.,  return  step  l),  or 

р.  Fix  maior  problems  and  release  to  NSWOPS;  i.e.: 

1.  ACC:  Direct  DMCs  to  correct  selected  bugs 
and  deliver  new  components  for  Candidate 
System  installation  ASAP. 

2.  PDC:  When  new  components  nave  been 
received  from  ACC  and/or  selected  DMCs, 
verify  (If  possible)  that  all  major 
problems  nave  been  corrected  and  no 
significant,  new  problems  nave  been 
introduced. 

3.  Proceed  witn  step  8 

с.  Release  to  nswops  (i.e.,  proceed  witn  Step  8) 
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8.  nSmOPS:  As  directed  by  PG,  prepare  for*  install  and 
operate  the  new  nsw  system  release  on  oenalt  of  tne 
NSw  user  community;  direct  and  coordinate 
installation/ooeratlon  activities  «ltn  DHC-CCn  and 
OMC-H1S, 

Delivery  of  a  new  NSw  system  release  to  PDC  for  3/A  is  a 
significant  event  in  tne  life  cycle  of  an  nsn  system  (see  Figure 
5-3).  It  signals: 

-  Completion  of  a  malor  amount  of  tne  wortc  associated 
with  a  given  release,  and 

-  beginning  of  woric  "in  earnest"  on  tne  next  malor  *S« 
system  release. 

A  further  reason  is  that,  as  a  result  of  PDC  0/A  activities,  it 
is  most  often  tne  case  that  PG  elects  to  nave  DNLtf  malor  proDlems 
corrected  (option  b  of  steo  7  above)  before  releasing  tne  system 
to  nsnops  tor  production  operation. 


NSW  System  Development  Life  Cycle 


5.4  Quality  Assurance  Tasting 


POC  (GSG)  nas  responsibility  for  assuring  tne  quality  of 
releases  submitted  by  ACC.  This  role  is  as  close  as  any  on  the 
nsm  project  to  "Independent  validation  and  verification",  a 
familiar  DoD  term.  PDC's  Q/A  tests  represent  tne  most  extensive 
and  complete  testing  a  new  NSW  system  receives  before  it  is 
released  to  nswups  for  production  operation.  PDC*s  Q/A  testina 
activities  have  evolved  into  the  following  logical  sequence  of 
steps: 

1.  Prepare  and  distribute  a  "Test  Plan"  for  the  new  nsw 
system  release  (see  for  example,  tne  "nsw  5.0  Test 
Plan"  (201 )  which  identifies: 

a.  The  current  set  of  "generic  configuration  items” 

(see  section  5.6) 

b.  Tne  status  of  all  outstanding  STR’s  (see  Section 
5.5)  including  specific  tests  prepared  for  each 
STR  addressed  by  the  new  system  release 

c.  The  nsw  host  and  software  component 
configurations  to  be  used  tor  tne  release 

d.  The  tests  to  be  applied  (see  below),  and 

e.  A  schedule  for  completing  testing  activities. 

2.  Update  existing  Q/A  test  procedures,  scripts,  etc*,  and 
devise  new  tests  as  necessary  (concurrent  with  Step  1). 

3.  Apply  Q/A  tests  (POC  and  nswops)  to  the  new  release 
(l.e.,  the  "Test  Plan"  is  carried  out  under  PDC*s 
direction.) 

4.  Prepare  and  distribute  a  "Test  Summary*  of  the  Q/A 
testing  activities  (see  for  example,  the  "nsw  5.0  Test 
Summary”  (211).  which  Includes: 

a.  An  overview  of  Q/A  test  results  and  recommendations 

b.  A  summary  of  significant  events,  which  occurred 
during  the  test  period,  which  impacted  Q/A  testing 

c.  A  summary  of  the  results  tor  each  type  of  testing 
(e.g..  regression.  STR-specif le.  etc.  —  see 
below). 
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d.  An  annotated  list  ot  new  STR*s  uncovered  durlno  0/A 
testing. 

Tne  "Test  Suaaary"  is  distributed  by  POC  to  PG  and  ACC.  On 
tne  basis  ot  tne  "Test  Suaaary"  and  input  troa  PDC ,  ACC  and 
NSnOPS.  PG  deteralnes  the  future  disposition  of  tne  new  NSW 
system,  as  discussed  in  Section  5.3. 

Tne  U/A  tests  applied  to  eaen  new  NSW  systes  are  ot  several 
different  types,  each  designed  to  test  different  integration 
levels  ot  NSW  functionality.  Tnese  tests  are  not  exhaustive,  but 
they  do  represent  a  significant  assessment  of  the  nsw 
functionality  provided  tne  user,  with  tne  exception  of 
STR-specific  tests.  O/A  testing  methodologies  nave  been  prepared 
tor  each  type  of  testing,  as  described  below: 

1.  STK-SPeclfic  Testing:  Prior  to  receipt  ot  a  new  nsw 
system  from  ACC,  POC  prepares  tests  tor  each  Software 
Trouble  Report  (STR  —  see  Section  5.5)  which  will  be 
addressed  by  tne  new  release.  These  tests  are  used 
to  verity  tnat  problems  nave  been  corrected  and  that 
no  new  problems  or  side-effects  nave  oeen  introduced 
in  the  process.  Also,  STR-specific  tests  are  used  to 
assess  new  and/or  improved  NS*  functionality.  These 
tests  are  documented  in  the  "Test  Plan"  which  is 
distributed  prior  to  the  beginning  of  the  0/A  testinq 
period  (l.e.,  prior  to  receipt  ot  a  new  release  from 
ACC). 

2.  Regression  Testing:  A  methodology  has  been  devised 
tor  regression  testing  new  NSw  releases.  It  a  system 
function  or  feature,  whicn  worxed  properly  in  the 
proceeding  release,  no  longer  functions  correctly  in 
the  new  release,  a  "regression”  is  said  to  have 
occurred.  Regression  tests  are  designed  to  uncover 
these  differences.  However,  the  nsw  regression  tests 
are  more  general  m  that  they  have  been  designed  to 
uncover  as  many  differences  as  possible  between 
successive  NSW  releases,  including: 

-  improvements 

-  Regressions,  and 

-  Problems  whicn  persist  from  one  release  to 
anotner 

•  Regression  tests  consist  of  a  number  ot  distinct  test 
scripts.  These  scripts  are  composed  ot  nsw  contend 
sequences  which  are  applied  to  tne  user  interface 
(exercising  user-visible  nsw  functionality).  Both 
application  ot  regression  test  scripts  (to  the  user 
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Interlace)  and  collection  of  NS*  system  responses  have 
been  automated.  The  steos  of  the  NSW  regression 
testing  procedure  are  summarized  below: 


1.  Update  regression  tests  as  necessary  to  reflect 
differences  between  the  successive  releases. 

2.  Use  automated  means  to  apply  test  scripts  to  the 
new  NSW  system  and  collect  responses. 

i.  Compare  (automatically)  the  responses  tor  each 
test  script  to  those  retained  fro*  the 
preceedlng  release*  and  sumnarlze  the 
incremental  differences. 

4.  Analyze  the  differences  (obtained  in  step  3)  to 
identify  improvements*  regressions  and  problems 
exhibited  oy  both  the  new  and  immediately 
preceeding  releases. 

5.  Prepare  and  submit  new  STR*s  to  ACC  tor  each 
regression  identified. 

.  This  procedure  is  simple*  yet  powerful  (identifying 
major  differences  between  successive  releases)  and 
efficient  (highly  automated). 

3.  File  Transformation  Testing:  File  transformations 
are  the  vehicle  which  NSW  provides  for  data  residing 
on  one  nsm  host  to  be  converted  into  a  form  which  may 
be  used  by  a  "tool"  (see  Section  6.1.3)  residing  on 
an  nsw  host  of  a  different  "family”  (see  Section 
4.3).  File  transformations  allow  the  output  of  one 
tool  to  be  used  oy  another  tool  of  a  different 
family.  Thus*  NSW  file  transformations  are  the  key 
to  success  of  tool  interactions  between  NSW  host 
families  (e.g.*  the  use  of  a  tool  followed  by  the  use 
of  a  tool  which  resides  on  a  host  which  belongs  to  a 
different  (incompatible)  family).  Conversion  of  an 
EBCDIC  character  file  reflding  on  an  IBM  host  to  an 
ASCII  character  file  during  movement  to  a  T0PS-2W 
host  is  a  simple  example  of  an  NSW  file 
transformation.  File  transformations  esbodv  record 
structure*  format  effectors*  as  well  as 
word/character  encodings.  Because  the  NSW  concept  is 
highly  dependent  on  these  transformations*  a 
"Methodology  and  Plan  for  Testing  File 
Transformation"  (22)  was  developed.  Due  to  the 
nature  of  the  differences  between  NSW  host  families* 
the  distributed  nature  of  the  NSW  file  system  (and 
its  protocols)*  and  the  date  translation  approach 
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adopted,  nsw  file  transformations  are  perhaps  one  of 
the  most  difficult  packages  of  NSW  system 
functionality  to  test.  Tne  file  transformation 
testing  methodology  is  aDDlied  to  new  NSW  system 
releases  to  verify  the  fidelity  of  this 
functionality.  A  simplified  version  of  the  basic 
procedure  is  outlined  below: 

a.  Update  the  "Methodology  and  Plan  for  Testinq  NSW 
tile  Transformations"  as  necessary  to  reflect 
incremental  cnanges  from  the  preceedlng  release. 

b.  Prepare  and/or  modify  file  transformation  test 
case  files,  as  necessary;  import  these  files 
into  the  nsw  Candidate  System. 

c.  Use  automated  means  to  force  file 
transformations  by  moving  test  case  files  from 
one  nsw  host  to  another  (these  hosts  may  or  may 
not  belong  to  different  host  families). 

d.  Analyze  resultant  files  to  determine  whether  the 
file  transformations  under  test  have  been 
successfully  completed. 

e.  Prepare  and  submit  STR's  to  ACC  for  each 
identified  file  transformation  anomaly  or 
problem. 

interactive  Tool  Testinq:  Tool  testing  is  concerned 
with  verifying  the  proper  operation  of  "tools” 
(executable  programs)  Installed  in  the  nsw 
environment.  Interactive  tools  are  the  most 
prevalent  type  of  nsw  tool  (see  Sections  6.1.3  and 
6.2.3).  Although  tool  testing  is  viewed  largely  as  a 
Tool  Manager  responsibility  (see  Section  3.1),  it  is 
an  area  which  GSG  addressed  during  the  NSW  system 
development  process.  Tool  operability  is  one  of  the 
most  important  concerns  of  NSw  user  community. 

Decause  tool  availability  is  the  user's  reason  for 
using  the  NSW  system.  Therefore,  GSG  developed  the 
"Interactive  Tool  Testing  Methodology"  (23)  and 
applied  it  to  a  number  of  nsw  tools  delivered  with 
nsw  release  5.0.  The  results  of  these  tests  are 
summarized  in  the  "Summary  of  Interactive  Tool  Tests: 
nsw  Release  5.4"  (24).  These  tests  win  be  applied 
as  necessary  to  (selected  sets  of)  the  tools 
delivered  with  all  future  NSW  releases. 


5.5  STR  Processing 


when  nsw  users,  contractors,  etc  uncover  suspected  problems 
with  the  nsw  software,  a  Software  Trouble  Report  (STR)  is 
prepared  to  document  the  problem,  m  addition.  STR*s  are  used  to 
report  system  deficiencies.  An  STR  includes  some  or  all  of  the 
following  information: 

-  Originator  (e.g.«  name  of  user  or  contractor) 

•  Description  of  the  problem,  deficiency  or  improvement 

•  Date  and  time  of  submission 

•  Type  of  problem  (component,  tool  or  documentation) 

-  Release  number 

-  Urgency 

-  fctc. 

STR *s  are  a  critical  part  of  tne  NSw  system  development 
process,  particularly  configuration  management  (see  Section  5.6) 
of  successive  NSw  releases.  Because  of  the  pervasive  use  of 
STR's  tor  reporting  bugs,  deficiencies  and  new  feature  reguests, 
NSw  system  releases  have  largely  become  STR-directed.  That  is, 
the  nsw  system  modifications  integrated  and  packaged  into  a 
system  consist  largely  of  components  delivered  by  Due's  wnich 
address  a  given  set  of  STR's  (including  deficiencies  and 
improvements). 

GSG ,  as  Product  Development  Contractor  (PDC),  developed  the 
procedures  and  protocols  for  the  original  STR  accounting  system. 
At  that  time,  STR's  were  Known  as  "NSW  Standard  Transactions”  (or 
NST's)  and  tne  accounting  system  was  Known  as  the  "NST  System”. 
The  NST  System  was  designed  to  oe  general  and  nigniy  flexible. 
nst's  were  envisioned  as  a  convenient  means  for  documenting 
and/or  tracKing  many  communications  ("transactions”)  other  than 
nsw  system  software  bugs,  including: 

-  Deficiencies 

•  Improvements 

•  Inquiries  (questions) 
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•  Operations  procedures 

•  Regularly  generated  reports 

-  Etc* 

Eventually*  the  large  nuaber  of  nst's  and  the  Informal* 
unregulated  protocol  for  interaction  between  nsm  organisations 
became  a  major  burden  to  users  of  tne  NS*  System*  Consequently* 
a  tool  tor  monitoring  STR's,  called  monstr  was  developed  by 
Massacnusetts  Computer  Associates  for  use  by  all  ns*  contractors* 
and  (eventually)  ns*  users.  MONSTR  serves  as  a  STR  repository 
and  Implements  a  more  rigid*  table-driven  protocol  for  the 
movement  of  STR's  between  NS*  organizations  on  tne  road  to 
resolution,  besides  implementing  the  protocol  tor  resolution  of 
STR's*  monstr  provides  a  number  of  other  facilities  including: 

-  Archiving  of  terminated  STR's 

-  Generation  of  STR  reports  by  STR  attribute  (e.g.*  by 
STR  identifier*  priority*  responsible  organization* 
etc. ) 

-  Etc. 

To  understand  the  role  STR's  Play  in  the  NS*  system 
development  process*  consider  the  following  example  (Figure  5-4): 

1.  An  NS*  user  creates  an  STR*  which  reports  a  suspected 
NS*  software  problem  to  NSWOPS. 

2.  After  reviewing  the  user's  STR*  NSWOPS  decides  that 
the  problem  is  legitimate  (l.e.*  neither  user 
misunderstanding  nor  error)*  but  decides  to  request 
additional  information  (e.g.*  a  typescript)  from  the 
user. 

3.  The  nsw  user  responds  by  supplying  NS*0PS  with  the 
information  (typescript)  requested. 

4.  nswOPS  assigns  a  priority  for  resolution  of  the  STR 
and  dispatches  the  STR  to  ACC.  (Note:  For  this 
example  we  shall  assume  that  the  problem  is 
interfering  dramatically  with  use  of  the  NS*  system 
and  that  a  high  priority  has  been  assigned  to  its 
resolution). 

5.  ACC  reviews  the  STR  and  dispatches  it  to  the 
appropriate  dmc  for  corrective  action  (Note:  If  more 
information  were  required  or  the  STk  were  not 
actually  a  software  problem*  it  would  be  returned  to 
NSWOPS). 
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6.  The  DMC  selected  by  ACC  addresses  the  problem  by 
preparing  a  new  component  version  which  is  delivered 
to  ACC  tor  integration  and  testing;  the  STR  is 
returned  to  ACC  with  an  analysis  of  the  problem  and  a 
description  of  the  fix. 

7.  ACC  integrates  and  tests  the  new  component  in  a  full 
nsw  system  configuration.  If  tne  new  component 
properly  addresses  the  STR.  it  is  passed  on  to  NSWOPS 
along  with  the  STR  (which  includes  a  user-oriented 
description  of  the  problem  and  now  it  was  rectified). 
Otherwise,  the  component  is  returned  to  the 
appropriate  DMC  for  additional  worx. 

8.  nswops  installs  the  component  (POC  may  elect  to 
perform  Q/A).  notifies  the  user  that  the  problem  has 
been  corrected,  and  "terminates*  the  STR. 

The  above  example  describes  the  means  by  which  a  high  priority 
problem,  substantially  impacting  use  of  the  nsw  system,  would  be 
resolved.  Note,  however,  that  STR's  are  normally  addressed  and 
integrated  into  valor  NSw  system  releases,  which  are,  from  the 
user's  point-of-view ,  spaced  many  months  apart. 
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5.6  Configuration  Management 


software  configuration  management  (CM)  is  a  discipline  for 
installing  software  changes  which  allows  the  evolution  of  a 
software  system  to  oe  tractced  and  controlled.  By  tractcinq  and 
controlling  software  changes.  CM  becomes  an  integral  part  of  a 
formalized  system  software  life  cycle  planning  and  development 
process.  Such  formal  development  discipline  becomes  extremely 
important  tor  projects  with  characteristics  similar  or  identical 
to  those  of  NSW.  namely: 

-  A  large  number  of  geographically  distributed 
contractors,  who  are 

*  working  autonomously  on  a  large  number  of  constituent 
software  components,  which  must,  ultimately,  be 

•  Integrated  into  a  workable  software  product. 

Software  CM  is  an  integral  part  of  the  plan  for  developing, 
maintaining  and  operating  me  NSW  system  ("The  NSW  Management 
Plan"  12) )  The  nsw  project  has-  collectively  been  working  toward  a 
CM  implementation  goal  since  ?he  beginning  of  the  contract  period 
covered  by  this  report.  GSG's  POC  organization  received  a 
majority  of  the  charter  and  responsibility  for  developing  NSW 
configuration  management  procedures. 

Software  CM  is  generally  viewed  as  a  continually  evolving, 
three-step  process: 

1.  Configuration  identification 

2.  Configuration  control 

3.  Configuration  auditing 

The  CM  approach  adopted  for  the  nsw  project  results  from  a 
collective  effort  on  the  part  of  both  PDC  and  ACC.  witn 
suggestions  and  input  from  ACC  (Massachusetts  Computer 
Associates).  GSG  has  prepared  a  "nsw  Software  Management  and 
Control  Plan"  126)  which  deals  with  each  of  the  above  CM 
activities  in  detail.  A  brief  characterization  of  eacn  CM 
activity  as  it  pertains  to  the  NSW  system  follows: 

*  CONFIGURATION  IDENTIFICATION:  This  is  the  process  Of 
identifying  the  objects,  celled  "iteee"  (e.g.,  programs, 
date  files,  etc.)  which  ere  to  be  controlled.  Each 
item,  without  e  specific  version,  is  celled  e  "generic 
configuration  item".  When  e  release  is  packaged,  e 
specific  version  is  identified  tor  each  generic 
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configuration  item  to  be  Included  with  the  release! 
items  which  include  version  identification  are  slmolv 
called  "configuration  items”  (Cl's).  PDC  and  ACC  agreed 
(with  concurrence  from  PG)  that  only  major*  aggregate 
items  of  the  NSw  system  would  be  placed  under 
configuration  control.  These  aggregate  items  include: 

•  NSW  software  component  executables 

-  nsw  "tool"  executables 

-  NSW  system  database  skeletons 

•  Host-independent  functional  specifications 

-  User  documentation 

-  Host-dependent  component  documentation 

•  operator  documentation 

Note:  This  list  of  aggregate  items  does  not*  for 
example*  include  the  constituent  source  and 
object  modules  for  each  component 
executable  (see  below). 

Configuration  management  of  source  and  object  modules  for 
each  software  component  (see  Section  4.4.1)  has  been 
delegated  to  the  DNC  responsible  tor  the  component 
implementation.  After  a  consensus  had  been  reached  on 
conf iguratldn  item  granularity*  PDC  developed  a 
methodology  for  identifying*  through  hierarchical 
decomposition*  the  "generic  configuration  items"  fpr  the 
nsw  system.  The  decomposition  consists  of  collections  of 
generic  Cl's  called  "packets”.  The  approach  taken  was  to 
first  identify  generic  Cl's  which  applied  to  more  than 
one  host  family  (l.e.*  the  entire  NSW  system)*  then  to 
Identify  generic  Cl's  which  apply  to  more  than  one 
software  component*  tool*  etc  of  a  host  family  (l.e.*  to 
the  entire  host  family)*  then  to  identify  the  Cl's  which 
apply  to  individual  host  family  component  implementations 
and  tools*  respectively.  The  Cl  packets  produced  by  this 
decomposition  are: 

1.  NSW  System  Packet  (Cl's  which  apply  to  multiple 
host  families) 

2.  tops-20  Host  Family  Packet*  containing  the 
following  subpackets 


a.  Generic  TOPS-20  packet  CCI's  which  apply  to 
more  than  one  TOPS-20  component  or  tool) 


b.  TOPS-20  component  pacxet(s)  Cone  for  each 
TOPS-20  component  implementation) 

c.  TOPS-20  tool  packet(s)  (one  for  each  TOPS-20 
tool) 

3.  IBM  Host  Family  Packet 

a.  Generic  IBM  packet 

b.  IBM  component  packet(s) 

c.  IBM  tool  packet(s) 

4.  Multics  Host  Family  Packet 

a.  Generic  Multics  packet 

b.  Multics  component  oacket(s) 

c.  Multics  tool  packet(s) 

5.  Unix  Host  Family  Packet 

a.  Generic  Unix  packet 

p.  Unix  component  packet(s) 

(Note:  There  are  currently  no  unix-Dased  ns*  tools) 

•  Because  of  autonomous  operational  requirements* 
configuration  management  of  the  IBM  and  Multics  Host 
Family  packets  (with  the  exceotion  of  configuration 
auditing  —  see  below)  have  been  delegated  to  DMC-CCN  and 
DMC-hlS »  respectively.  Generic  configuration  items  for 
both  the  "NS*  System"  and  "TOPS-20  Host  Family"  packets 
are  enumerated  in  Appendix  B  of  this  report. 

•  nsw  organizational  and  contractor  responsibility  for 
configuration  management  of  the  above  packets  (as 
installed  in  tne  various  ns*  configurations  used  for  nsn 
system  development)  is  summarized  below: 

-  Debug  System:  ACC  (COMPASS) 

-  Development  System:  ACC  (COMPASS) 
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Candidate  System:  PDC  (GSG) 
User  Svstea:  nswops  (GSG) 


*  CONFIGURATION  CONTROL:  Once  configuration  items  have 
been  identified  and  CH  procedures  Implemented#  a  large 
part  of  tne  "fixed  cost"  associated  with  configuration 
management  is  done.  The  following  disciplines  are  the 
major  constituents  used  to  control  (lncreaental )  NSW 
software  changes: 

1.  Autonomous  Component  Development:  OMC’s  are 
responsible  for  development  and  maintenance  of 
individual  NSW  software  components.  ACC  is  largely 
responsible  for  directing  dmc's  to  mate  software 
changes  and  upgrades.  DNC's  modify  and  deliver 
software  components  which  reflect  tne  changes 
requested  by  ACC  or  suggested  by  the  DMC*s.  ACC 
completely  controls  integration  of  new  component 
versions  into  fully  operable  NSW  system 
configurations. 

2.  Autonomous  NSW  System  Configuration:  Associating  a 
separate  nsw  system  configuration  with  each  major 
stage  of  the  NSw  system  development  process,  and 
delegating  control  for  each  configuration  to  a 
single  nsw  organization  (see  section  5.1)  provides 
the  mechanism  for  controlling  Changes  to  the  NSW 
system  during  the  NSW  system  development  process. 

3.  Release  Packaging:  When  preparing  a  system  release 
tor  delivery  tv  PDC ,  ACC  is  required  to  make  all 
software  changes  known  to  PDC  and  NSWDPS.  Software 
changes  directed  by  ACC  usually  take  one  of  two 
forms: 

-  A  fully  specified  enhancement  which  must  be 
implemented  by  at  least  one  DNC#  or 

-  An  STR  which  documents  a  problem#  deficiency  or 
improvement  (STR's  are  accessible  to  NSW 
contractors  through  MONSTR  -•  see  Section  5.5). 

Because  ACC  controls  the  integration  process# 
it  is  likely  that  most  nsw  software  changes  are 
communicated  to  ACC  oy  the  DNC's#  which  can  in 
turn  be  communicated  to  PDC  prior  to  delivery 
of  a  new  release  for  0/A. 

However#  because  of  autonomous  and  asynchronous 
component  development  practices#  it  is  possible 
tor  dnc's  to  make  changes  to  components  wnlch 
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are  never  Known  by  ACC.  Since  PDC/NSWOPS  must 
rely  on  ACC  for  a  complete  and  accurate  Picture 
of  the  incremental  software  changes  which 
comprise  any  given  release,  we  should  note  that 
this  approach  to  configuration  management  is 
not  foolproof.  However,  experience  Indicates 
the  level  of  formality  and  control  which  has 
been  achieved  is  sufficient  to  assure  smooth 
evolution  of  the  NSW  system. 

*  CONFIGURATION  AUDITING:  Configuration  auditing  is  the 
process  dv  which  information  is  obtained  on  the  current 
state  or  past  history  of  an  installed  set  of  NSw 
configuration  items.  One  of  the  most  important  aspects 
of  configuration  auditing  is  the  ability  to  identify 
differences  between  any  two  sets  of  NSW  configuration 
items  (e.g..  system  or  component  releases).  Such 
procedures  are  extremely  important  in  the  nsn  context 
because  of  IBM  and  Multics  host  family  autonomy  (see 
Section  S.l).  For  example,  auditing  allows  ACC.  PDC  and 
nswops  to  determine  what  changes  (if  any)  nave  been  made 
in  the  sets  of  IBM  or  Multics  host  (family) 
configuration  items  (installed  in  tne  NSW  Development. 
Candidate  or  user  system  configurations)  without 
maintaining  control  over  the  set  of  installed  Cl's. 
Configuration  auditing  procedures  nave  been  implemented 
and  are  regularly  exercised  in  each  NSW  system 
configuration  (i.e..  the  Development.  Candidate  and  User 
Systems) . 
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5.7  nsw  Release  History 

Version  3.1  of  the  NSw  system  was  installed  in  the  nsw  user 
System  configuration  just  prior  to  the  contract  period  covered  by 
this  report.  Two  (2)  major  and  one  (1)  Incremental  reiease(s) 
occurred  during  the  past  contract  period.  The  salient  features 
of  each  release  are  outlined  belowt 

nsw  version  4.0:  A  major  NSW  system  release  addresslnq 
several  STR's  and  also  including  a  few  significant#  but 
largely  operator-visible  (i.e.#  user-invisible) 
enhancements. 

-  Released  to  PDC  for  Q/A:  May  2#  1979 

-  Major  improvements: 

Support  for  TOPS-20  version  101B 
First  release  of  the  Fault  Logger  component 
New  Checkpolnter  and  TOPS-20  Foreman  components 
improved  operator  interface 
More  robust  Muitlcs  TBH 

separate  descriptors  for  each  tool  executable 

.  Package  logs  (component  compi ling/llnklng 
prescriptions) 

-  STR's  Addressed:  unknown 

-  Testing  Completed  by  POC:  August  14#  1979 

-  STR  fixes  falling  Q/A:  Unknown 

-  New  STR's  identified:  300+  (action  suggested  bv 
PDC  on  128) 

-  Major  (New)  Problems: 

Database  Integrity 

•  Improved  component  resilience  (especially 
TOPS-20  MSG) 
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Protocol  violations 


Resource  consuaDtion 
User  interface  anomalies 

-  Released  to  as*  Users:  Never;  uoqraded  to  NSW  4*1. 


nsw  version  4.1:  An  incremental  upgrade  of  NSW  release 
4,(4/  addressing  many  of  tne  orobleas  mentioned  above  under 
nsw  version  4.0. 

-  Released  to  POC  for  O/A:  Septenoer  18,  1979 

-  Major  improvements: 

Database  integrity  Droolems  resolved 

.  Component  resilience  (new  TOPS-20  MSG  and 
Foreman,  and  IBM  Foreman  component(s) ) 

Several  protocol  violations  rectified 

.  Resource  consumption  (unnecessary  component 
instances  and  activations)  improved 

.  User  Interface  (error  messages,  control 
characters  and  connection  handling) 
significantly  upgraded 

•  sir's  Addressed:  69 

-  Testing  Completed  by  PDC:  September  28,  1979 

-  STk  Fixes  Falling  0/A:  9 

•  New  STR's  identified:  49  (most  of  these  were 
scheduled  to  be  addressed  by  NSW  version  $.0  ••  see 
belo*) 

•  Major  (new)  problems: 

Reliability  scenario  failures 
TOPS-20  MSG  link  allocation  problems 
Local  TOPS-20  msg  failures 
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Forcibly  terminated  components 
Front  end  failures 
Node  size  limitations 

•  Released  to  NSW  users:  October  5,  1979 

NSW  Version  5.0:  A  major#  new#  largely  SiR-directed  NS* 
system  relase  also  concentrating  on  release  transition  and 
conf iguration  management  procedures. 

•  PDC  "Test  Plan":  July  30,  1980 

•  Released  to  PDC  for  Q/A:  July  31#  1980 

•  Major  improvements: 

Support  for  TOPS-20  version  4;  more  resilient 
TOPS-20  MSG 

New  TOPS-20  Foreman  component  (woricspace 
creation#  archiving  and  reliability  scenarios) 

User  interface  improvements  [restored  tools# 

Foreman  workspace  and  file  delivery  prompts) 

Multi cs  TBH  more  robust 

•  STR's  addressed:  65 

-  0/A  testing  completed  oy  PDC:  August  29#  1980 

•  PDC  "Test  Summary":  September  11#  1980 

•  nswops  "interactive  Tool  Test  Summary":  November 
14#  1980 

•  STR  fixes  tailing  0/A:  8 

•  New  STR's  identified:  67 

-  Major  (new)  problems: 

TOPS-20  MSG  and  Front  End  failures  (most  of  the 
problems  in  this  area  were  diagnosed  and 
corrected  before  release  of  nsw  5,0  to  users) 


6.0  nsw  User  Interface 


In  the  first  of  two  major  sections  which  follow,  we  provide 
the  reader  with  a  user-oriented  overview  of  NSw  functions  and 
capabilities.  This  first  section  sets  the  stage  for  tne  second 
section  which  summarizes  and  discusses: 

-  Tne  current  status  of  the  NSW  user  System 

•  Progress  (during  the  contract  period  covered  by  this 
report)  in  evolving  the  NSw  concept,  and 

•  Future  directions  dictated  by  Known  requirements, 
deficiencies  and  problem  areas 


6.1  overview  of  ns*  Capabilities 

The  NS*  system  operates  in  a  networking  environment  and  is 
analogous,  in  its  functions  and  capabilities,  to  a  single-host 
operating  system.  In  particular.  NS*  implements  a  standard 
command  interpreter,  providing  NSW  users  with  uniform  access  to 

-  Files  resident  in  nsw's  distributed  file  system 

•  Tools  available  on  NS*  hosts  in  the  NS*  system 
configuration. 

In  addition.  NS*  Incorporates  a  built-in  project  management 
facility  which  provides  project  managers  with  a  vehicle  for 
delegating  responsibilities  and  implementing  informal  protocols 
among  project  members.  An  overview  of  NSw's  project  management 
capabilities,  tile  system,  tools  and  command  language  are  each 
covered  oy  the  individual  subsections  whicn  follow. 


6*1.1  Project  Management 

Tne  project  management  facilities  of  NSW  are  an  integral 
part  of  its  desiqn*  Each  new  nsw  user  is  assigned  a  "project",  a 
"node"  and  a  "password",  which  must  be  supplied  during  the  NSW 
authentication  sequence  (l.e*.  LOGIN).  Tnus.  a  user  wishing  to 
use  nsw  facilities  first  logs  m  to  tne  assigned  node  of  his/her 
project.  The  user's  login  node  establishes  a  context  tor  tne 
duration  of  tne  his/her  NSw  session. 

nsw  projects  are  collections  of  nodes.  Much  like  the 
organizational  structure  of  many  companies,  the  nodes  of  a 
project  form  a  hierarchy  (also  called  a  "project  tree").  Each 
node  must  have  a  "supervisory"  parent  and  may  nave  zero  (0)  or 
more  sons,  we  say  that  a  given  node  was  "created"  by  its  parent 
and  that  a  node  (with  the  appropriate  "right"  -  see  below)  may 
act  as  a  "supervisory"  parent  by  creating  sons  of  its  own. 

(Note:  since  a  node  establishes  the  context  for  a  user's  NSW 
session,  the  terms  "node"  and  "user"  may,  at  tines,  be  used 
interchangeably).  Nodes  establish  a  context  by  acting  as 
place-noiders  for  tool  and  file  access  "rights".  Associated  with 
each  node  is: 

•  A  list  of  tools  which  may  be  accessed  (used)  by  that 
node,  and 

-  A  list  of  file  "keys"  controlling  access  to  named 
(groups  of)  NSW  files. 

A  node  may  receive  rights  from  any  "supervisory"  parent  in 
the  tree  of  which  the  node  is  a  direct  descendent.  A  node  may 
give  any  of  its  rights  to  any  of  one  or  more  of  its  sons  (or 
their  sons,  etc.). 

nsw  provides  built-in  project  management  tools  tor: 

•  manipulating  (creatinq  and  deleting)  nodes  (or 
sub-trees)  of  the  project  tree 

-  Assigning  rights  to  and  removinq  rlqhts  from  a  son  node 

•  Examining  nodes  of  the  project  tree  and  their  tool/tile 
access  rlqhts 

These  project  management  tools  are  governed  by  tool  rights  as 
well,  tor  example,  a  user  (node)  wisning  to  create  a  (new)  son 
node  must  nave  received  rights  for  the  "create  node"  tool  from  a 
"supervisory"  parent. 
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To  illustrate  NSW  project  management  capabilities,  consider 
the  following  example.  Initially,  tnere  is  one  node  (node  "A") 
in  the  project  tree  (see  Figure  6-1)  with: 

Tool  rights  for: 

-  All  NSW  project  management  tools: 

Create-node 

Delete-node 

Examine-node 

Assign-rights 

Remove-rights 

•  A  small  set  of  program  development  and  documentation 
tools: 

Teco  la  text  editor) 

PL/1  (load  and  qo  compiler) 

Runott  (a  text/document  processor) 

File  rights: 

A  and  b 

.  (Note:  A  and  B  are  called  "Keys"  to  tne  NSW 
namespace  for  files.  NSW  filenames  consist  of  a 
number  of  "components"  separated  by  periods  ("."). 

For  example,  " A.PROJ .TEAW"  is  an  NSw  filename  with 
separate  components.  Tne  "Keys"  A  and  B  may  be  used 
to  access  any  NSW  file  whose  name  begins, 
respectively,  wltn  the  component  A  or  tne  component 
B.  Tne  notion  of  NSw  file  riqnts  has  oeen 
simplified  somewhat  tor  this  example:  for  additional 
information.  Please  refer  to  tne  NSw  Users* 

Reference  manual"  12 7 J ) • 

using  the  create-node  tool,  node  A  creates  nodes  B,  C  and  D, 
then,  using  tne  assign-rights  tool,  gives  each  new  node  the 
rights  shown  in  Figure  6-2.  The  rights  assigned  oy  node  A  allows 
only  node  D  to  create  new  nodes  (node  D  can  not,  however,  delete 
son  nodes).  Also,  nodes  B  and  C  have  a  more  restricted  set  of 
file  rights  (i.e.,  "view"  of  nsw  fllespace)  than  node  D.  In 
fact,  node  D  can  access  any  tile  wnlch  nodes  B  or  C  can  create  or 
access,  but  because  node  u  has  the  more  general  file  right  "A", 
it  can  also  create  or  access  tiles  which  nodes  B  and  C  can't 
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(e.g.,  tiles  beginning  with  A.D),  Continuing  with  our  example, 
node  0  creates  three  new  son  nodes  (DA,  OB  and  OC)  assigning  each 
the  rights  shown  in  Figure  6*3.  After  surveying  the  project  tree 
with  the  "examine  node"  tool  (which  can  not  be  shown 
diagramatically  here)*  node  A  implements  the  following  project 
management  decisions: 

-  Mode  B  will  not  be  needed;  node  A  uses  the 
"delete-node”  tool  to  delete  node  B  (Figure  6-4) 

•  Node  A  notices  that  node  D  has  been  overzealous  in 
creating  new  son  nodes;  node  A  uses  the  "remove 
rights"  tool  to  revoke  the  "ereate-node"  tool  right 
from  node  0  (Figure  6-5) 

-  Node  DB  needs  temporary  access  to  some  NSb  files 
which  begin  with  B.A.  Node  D  cannot  access  files 
beginning  with  B,  so  s/ne  reguests  assistance  from 
node  A.  Node  A  temporarily  assigns  tile  right  B.A  to 
node  OB  (see  Figure  6-6),  out  not  to  node  0  who 
doesn't  need  it. 

In  this  example,  we  nave  examined  tne  nsm  project  management 
capabilities  tor: 

•  Creating  and  deleting  son  nodes,  and 

-  Assigning  and  removing  tool  and  file  rights. 

we  have  also  tried  to  provide  feeling  tor  tne  managerial  actions 
which  may  be  implemented  by  project  directors  and  team  members 
who  use  tne  nsw  project  management  tools. 
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^Tools :  create-node,  delete-node 

assign-rights,  remove-rights, 
examine-node , 

■1 


teco,  PL/I,  runoff 


t 


File  Rights:  A,  B 


J 


Project  Node  A  and  Tool/File  Rights 


Figure  6-1 
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•^File  Rights:  A.b^ 


jTools :  create-node ,  delete-node , 


assign-rights,  remove-right 
examine-node. 


teco,  PL/I ,  runoff  > 
®  |File  rights:  A,  B 


©  '  © 

■{Tools:  teco,  PL/I^  ^Tools:  create-node, 

^ File  Rights:  A.C_j  assign-rights 

examine  node 
teco,  runoff  } 
■^File  Rights:  aJ' 


Node  A  Creates  Nodes  B,  C,  D  and  Assigns  Tool/File  Rights 


Figure  6-2 


Tools :  none  ^ 

File  Rights:  A.B  } 


vsy 

|  Tools: 


none 


£  Tools:  create-node,  delete-node,  assign- 

rights,  remove-rights,  examine-node 
I  teco,  PL/I ,  runoff  J 

^  File  rights  A,  B  j 


J  l  Tools: 


runoff , 


create-node 
assign-rights , 
examine-node , 
teco,  runoff J 
^  (File  Rights:  A  j- 

(pc) 

teco ,  i 

4  Tools :  \ 

1  runoff,) 


(  File  Righ  s.  A-D-A)^File  Rights:  A.D.bJ  {File  Rights:  A.D.cJ 


Node  D  Creates  Nodes  DA,  DB,  DC  and  Assigns  Tool/File  Rights. 


Figure  6-3 


R 


Tools:  teco,  PL/l) 
File  Rights:  A,cJ^ 


^J^A}  |  Tools:  create-node,  delete-node, 

.  assign-rights,  remove-rights, 

\  examine-node,  teco,  PL/ I,  runoff} 

\  | File  Rights: A,  B J 

y_  ^Tools:  create-node, 

assign-rights , 

/  \  examine -node , 

/  n.  teco,  runoff 

/  N.  {^File  Rights:  A_) 

(6b)  (j^) 

•( Tools:  teco, runoff )  l  Tools:  teco,  runoff^ 


|  Tools:  none_J  { Tools :  teco,  runoff,)  )  Tools:  teco,  runoff^ 

^File  Rights:  A.D.A  J  ^File  Rights:  A,  D, B  J  jjile  Rights:  h.D.C  } 


Node  A  Deletes  Node  B 


Figure  6-4 


'Tools:  teco,  PL/l) 
File  Rights:  A.C  ^ 


^ Too Is :  create-node,  delete-node, 

assign-rights,  remove-right, 
examine-node,  teco,  PL/I,  runoff 
|  File  Rights  A,  B  J 

jn  -'Tools:  assign-rights, 

""'V  e  xami  ne  -  node , 

\  runoff/ 

\  j File  Rights:  aJ 


teco. 


teco. 


£  Tools:  none^  {Tools:  runoff)  ^Tools:  runoff J 

[File  Rights:  A.D.AJ  {File  Rights:  A.D.Es)  jtile  Rights:  A.D.c} 


Node  A  Revokes  Node  D's  "Create-Node"  Right 


Figure  6-5 


Node  A  Assigns  File  Right  B.A  to  Node  DB,  But  Not  to  Node  D 


Figure  6-6 


6.1.2  The  NSW  File  system 


The  NSW  operating  system  provides  its  users  with  a  uniform 
and  coherent  vle«  of  tne  NS*  file  system.  The  ns*  file  system  is 
distributed  across  the  set  of  network  hosts  participating  in  the 
nsn  system  configuration  (i.e.,  those  NSW  hosts  participating  as 
File  Bearing  Hosts  —  see  Section  4.4.4);  hosts  participating  in 
the  nsw  file  system  provide  support  for: 

-  Movement  of  tiles  between  "native”  host  file  systems 
and  NSW  fllespace 

•  Storage  of#  and  access  to  tiles  in  NSW  fllespace 

-  Movement  of  tiles  between  NSW  nosts  (as  necessary) 

-  Data  translation  durinq  movement  of  a  tile  from  one  NS* 
host  to  another  (as  necessary) 

In  tne  name  ot  uniformity  and  coherence.  NS*  tries  to  make 
as  many  aspects  of  file  access,  movement  and  translation 
transparent  to  tne  NS*  user. 

The  following  example  illustrates  tne  tile  system  functions 
listed  above,  including  the  level  of  transparency  achieved  by  the 
nsw  system.  For  the  purposes  ot  this  example,  an  NSw  file  named 
"A"  (containing  text)  is  stored  on  the  UCDA-CCN  nsw  host.  An  NS* 
user  would  like  to  create  a  copy  ot  NS*  file  A  in  local  directory 
<B>  on  the  kadc-20  NS*  host  under  tne  name  "A. TXT".  (The  act  of 
copying  a  tile  from  nsw  fllespace  into  tne  "native"  host  file 
system  is  called  "exporting  a  file  from  NS*  fllespace".)  NSW 
provides  a  user  command  tor  "exporting"  files,  which  requires 
only  that  the  user  designate  the  name  ot  tne  nsw  tile  to  be 
exported,  and  where  in  the  "native"  file  system  it  is  to  be 
placed  (i.e..  name,  directory,  password,  etc.).  To  the  nsw  user, 
the  tile  export  is  a  single  command,  tor  which  a  positive  or 
negative  acknowledgement  is  received.  However,  to  complete  the 
export  operation,  the  underlying  nsw  macninerv  must  proceed  as 
follows  (see  Figure  6*7): 

1.  Move  tile  a  from  tne  nsw  fllespace  on  UCLA-CCn  NS* 
nost  to  the  NS*  fllespace  on  the  radc*20  NS*  host. 

2.  'Translate  the  file  as  it  is  moved  from  UCDA-CCN  to 
KA0020  (tile  translation  is  required  because 
UCLA-CCN  and  RAOO20  belong  to  two  very  different 
(i.e.,  incompatible)  nost  families).  As  a  minimum, 
character  conversion  (from  FBCDIC  to  ASCII)  is 
required. 


3.  Place  a  copy  of  tne  translated  file  in  RAD02U 
directory  <B>  under  tne  name  "A.lxT". 

4.  Notify  tne  ns*  user  that  the  export  operation  has 
been  successfully  completed. 

Note  that  all  of  the  file  "motion”  and  translation  activity 
remains  invisible  to  the  NS#  user* 
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6.1.3  NSW  Tools 


The  NSW  operating  system  provides  support  tor  tour  (4) 
different  tool  types;  each  of  these  may  be  characterized  briefly 
as  follows: 

1.  Management  Tools:  These  tools  are  tightly  coupled  to 
and  deeply  imbedded  in  the  NSW  software;  they  are 
used  to  manipulate  special  NSW  project  management 
entities  called  "nodes"  and  "rights"  (see  Section 
6.1.1)  1281. 

2.  NSW  Tools:  These  tools  are  implemented  using  special 
nsw  operating  system  primitives  specifically  designed 
to  support  the  construction  of  "NSW  tools".  No  tools 
of  this  type  presently  exist.  See  the  "NSW  Tool 
Builder's  Guide"  (29J  for  a  discussion  of  the  nsw 
primitives  available  to  tool  builders. 

3.  Batch  Tools:  These  tools  are  characterized  by 
"staged"  execution.  That  is.  the  user  must  supply 
all  parameters,  including  input/output  filenames,  job 
control  parameters,  etc  prior  to  tool  execution; 
these  tools  are  not  user-interactive  except  during 
the  period  that  runtime  parameters  are  collected.  A 
job  number  is  assigned  to  each  batch  tool  execution; 
the  user  may  query  the  status  of  a  job  and 
automatically  receives  notification  when  the  job  has 
been  completed  (or  terminated). 

4.  interactive  Tools:  These  tools  are  characterized  by 
direct  user  contact  and  interaction  during  execution. 
They  differ  from  Management  and  NSW  tools  in  tnat 
they  are  neither  imbedded  in  the  NSW  software  nor 
maxe  use  of  special  NSW  operating  system  primitives. 
Most  interactive  tools  are  copies  of  tools  which  have 
been  built  for  and  are  regularly  used  in  the  "native” 
host  (family)  environment.  Using  a  technique  called 
"encapsulation",  these  "native"  tools  are  regularly 
installed  in  the  NSW  system  without  modification, 
"encapsulation"  is  the  technique  used  to  mediate  all 
interactions  between  the  tool  ana  its  execution 
environment  (i.e.,  operating  system  calls);  this 
includes  (re)directlng  file  references  to  either  the 
nsw  system  or  the  "native"  host  operating  system. 

Each  interactive  tool  instance  is  executed  in  an 
assigned  area  called  a  "worxspace";  the  user  model 
tor  Interactive  tools  is  complicated  somewhat  by  the 
use  of  workspaces  tor  tool  execution  (see  the  example 
below).  Head  operations  cause  NSW  tiles  to  be  moved 


into  the  workspace  for  the  duration  ot  the  tool 
session;  new  flies  or  versions  (of  existing  nsw 
files)  are  also  placed  In  tne  workspace  during  tool 
execution.  Upon  termination  of  the  tool  session,  the 
user  may  elect  to  "deliver"  new  and/or  modified  files 
from  tne  workspace  into  NSw  fliespace* 

To  illustrate,  consider  tne  manner  in  which  the  interactive 
editor  XED  (available  on  many  TOPS-20  hosts,  including  the 
RADC-24)  is  used  to  modify  NSW  file  "A"  stored  in  NSW  tilespace 
at  UCLA-CCN: 

1.  Tne  nsw  user  invokes  the  XED  tool. 

2.  NSW  assigns  a  workspace  for  the  XED  tool  Instance, 
starts  execution  of  XED  in  the  assigned  workspace, 
and  places  the  NSw  user  in  contact  with  the  XED 
instance  (Fiqure  6-8). 

3.  The  NSw  user  reads  file  A  from  NSW  tilespace  (Figure 
b-9);  it  is  translated  and  moved  from  ucla-CCn  to 
RAUC-20,  then  into  tne  assigned  workspace,  and 
accessed  by  XED. 

4.  The  NSw  user  modifies  file  A,  creating  tile  b  stored 
In  the  workspace  (Fiqure  6-10). 

b.  The  nsw  user  reads  file  A  from  tne  workspace,  then 
modifies  and  creates  a  new  version  ot  tile  A  (A*  is 
used  to  distinguish  between  the  original  version  ot 
file  A  and  the  new  workspace  version)  in  the 
workspace  (Figure  b-li). 

6.  The  nsw  user  terminates  his/her  XED  session  (i.e., 
quits  XED)  and  confirms  delivery  of  tne  modified 
version  ot  tile  A  (A*)  and  new  tile  d  into  NSw 
tilespace.  Note:  Because  a  new  version  ot  tile  A 
(A*)  was  delivered  into  nsw  tilespace,  file  A  is  no 
longer  stored  at  UCLA,  but  rather  in  the  RADC-20 
portion  of  NSW  tilespace  where  it  was  delivered 
(Figure  b-12). 

7.  NSW  deallocates  the  workspace  assigned  to  the  XED 
instance. 


89 


RADC-20 
DEC  System-20 
.  TOPS-20 


RADC-20 
■*  ten- 20 
TOPS-20 


TOPS -20 


DECSys 


6.1*4  N5w  Command  Language 


nsw  provides  a  number  of  user  commands.  These  can  be 
categorized  and  summarized  as  follows: 

1.  User  Session  Management: 

-  Change  password 

-  Terminate  user  session  (logout) 

2.  NSW  File  Manipulation 

•  Move  tile(s)  between  "native"  host  tile  system(s) 
and  NSW  tilespace 

*  Copy,  delete  and  rename  NSw  tiles 

-  Lock  (set  a  semaphore  on)  an  NSW  file 

-  Change  specificity  (the  "scope”)  of  file  Key 
references 

3.  Tool  Session  Management: 

-  instantiate  (request  use  of)  a  tool  instance 

*  Abort  an  active  tool  session 

•  Resume  an  interrupted  (e.g.,  due  to  host  crash) 
tool  session 

4.  information  and  Status  Query: 

-  inquire  about  the  status  of  a  batch  lob 

-  Display  node  attributes  (e.g.,  sons  and  rights)  of 
the  user's  login  node 

-  List  names  of  files  (which  may  be  accessed  by  the 
node) 

-  List  file  Key  "scopes"  (see  "nsw  File  Manipulation" 
commands  above) 
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6.2  Current  NSW  User  system  status  (May  1981) 


The  subsections  which  follow  summarize  the  evolution* 
progress  (both  user-visible  and  user-invisible)  and  current 
status  of  the  nsw  system  for  the  period  covered  by  this  report. 

The  nsm  software  system  has  improved  dramatically  in  the 
last  two  years,  much  of  the  progress  is  of  a  form  which  is  not 
directly  user-visible  (primarily  because  so  many  NSW  services  are 
transparent  to  users).  At  the  same  time#  the  progress  is  so 
substantial  that  the  absence  of  this  progress  would  mean  an  NSm 
system  for  which  NSW  users  would  most  definitely  discern  ("feel") 
a  difference.  During  the  contract  period  covered  by  this  report* 
the  NS«  system  has: 

1.  Become  easier  to  operate 

2.  embodied  greater  economy  of  concept  (and  has  become 
easier  to  use) 

3.  Reduced  resource  consumption  dramatically 

4.  improved  in  performance  and  user  responsiveness 

5.  Achieved  more  reliable  and  robust  operation 


6.2.1  NSW  Command  Language  Status 


The  nsw  user  Interface  (including  tne  nsw  command  language 
and  its  interpretation)  is  largely  implemented  by  the  Front  End 
component  (and  its  interactions  with  other  NSW  components*  such 
as  the  wortcs  Manager).  Pernaps  the  most  significant  achievement 
in  this  area  has  been  the  addition  of  a  new  (alternative) 
Unix-based  Front  End  component.  The  Unix  Front  End  Implements  a 
somewhat  richer  user  interface  and  command  set  (including*  for 
example*  "immediate  command  return  mode"  which  allows  NSW  users 
to  initiate  multiole*  concurrently  executing  NSW  commands  —  see 
Section  6.1.4).  However*  the  syntax  for  NSW  commands  implemented 
by  the  Unix  Front  End  differs  visibly  from  that  which  was  adopted 
for  tne  TOPS-20  Front  End.  Plans  nave  been  made  for  installing 
the  Unix  Front  End  on  tne  AFLC  "base  system”  configurations 
(PDP-11 *s  running  Unix)  for  the  AFLC  Technology  Demonstration. 
This  new  component  has  not  yet  been  released  for  0/A  or  installed 
in  the  nsw  user  System  configuration. 

No  new  commands  or  user  capabilities  of  the  Xlnd  mentioned 
above  (e.q.,  "immediate  command  return  mode")  nave  been 
incorporated  into  the  TOPS-20  Front  End  implementation.  The 
command  language  Implemented  corresponds  to  the  commands  listed 
in  Section  6.1.4.  To  provide  the  nsw  user  witn  the  best  user 
Interface  possible*  significant  TOPS-20  Front  End  modifications 
were  made.  These  modifications  addressed  the  following  user 
concerns: 

-  Component  reliability* 

-  Tool  connection  management* 

-  Error  reporting,  and 

-  Consolidation  of  user  interface  (Including  control 
character  functionality,  consistent  prompting*  command 
consolidation,  etc.). 
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6.2.2  NS*  Flic  System 

Improvements  In  tne  NS*  tile  system  largely  depend  upon  the 
evolution  of  the  various  host  family  implementations  of  the  File 
Package  component.  Progress  in  this  area  can  be  summarized  as 
follows: 

1.  A  new.  more  efficient  Implementation  of  the  TOPS-20 
File  Package  component  was  introduced. 

2.  The  IBM  and  Multlcs  File  Package  implementations 
became  more  dependable  and  reliable. 

3.  The  following  new  file  types  (by  host  family)  were 
Incorporated  into  the  corresponding  host  family 
implementations  of  the  File  Package: 

TOPS-20  (2): 

-  10X-TEXT 

-  1 0X-SOSTXT 
IBM  (  ): 

-  360-ASM-OBJ 

-  360-MACR20-OBJ 

-  360-COBOL-SEQ-SOURCE 

-  3 60- ASM -SOURCE 

-  J60-PLM80-OBJ 

-  3 6 0-PLM8 0-SOURCE 

-  360-OVEHPRINT 

-  360-ASM80-SOURCE 
Multics  (2): 

-  MTX-TEXT 


MTX-HBRARY 


Unix 


**  none  ** 

•  (Note:  A  Unix  host  family  implementation 
of  the  File  Package  component  Poes  not 
presently  exist.) 

4.  nsw  file  transformations  nave  been  comprehensively 
tested  and  major  problem  areas  identified 

5.  Protocol  modifications  nave  been  designed  to  improve 
user  reliability*  user  error  reporting*  and 
performance 

Presently*  tne  best  (if  not  tne  only  reasonaole)  measure  of 
NSw  file  system  status  is  the  number  of  file  types  supported  by 
each  host  family  (see  Table  6-1). 
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TOPS-20  (3)* 

-  10X-BINARY 

-  10X-TEXT 

-  lax-sosiExi 

Multlcs  (2)1 

-  MTX-TEXT 

-  MTX-LIBRAR* 

IBM  (30): 

-  360-TEXT 

•  360-ORIGINAL-BIN 

-  360 -MACRO20 -SOURCE 

-  360-ASM-OBJ 

-  360-BINART 

-  360-MACRO20-OBJ 

-  360-OBJECT 

-  360-COBOL-SEU-SOURCE 

-  360-COBOL-SOURCE 

-  360-ASM-SOURCE 

-  360-PLI-CC-SOURCE 

-  360 -PUI-CC-C ARDS 

T«t>le  6-1 

NSw  File  Types  by  Host  Easily 


1»0 


Table  6-1  (continued) 


-  360-PLI -CARDS 

-  360-JCL 

-  360-ORIGINAL 

-  360-PL*80-OBJ 

-  360-CHS2M-OBJ 

-  360-OVERPRINT 

-  360-SPPCOBOL-SOURCE 

-  360 -PLM 80-SOURCE 

-  360-PLI- SOURCE 

-  360-CNS2M -SOURCE 

-  360-ASH 80 -SOURCE 

-  360-LOAD 

-  360-FORTRAN-SOURCE 

-  360-CARDS 

-  360-LIST 

-  360-PRINT 

-  3b0-KEYPUNCH 
Unix: 

**  not  applicable  »* 

Table  6-1 

NS*  File  Types  by  Host  Family 


fa. 2.3  NSW  Tools 


Significant  progress  has  oeen  achieved  in  establishing  tool 
management  procedures  and  improving  the  level  of  tool  support 
provided  by  the  NSW  system. 

The  nsn  Tool  Manager  has  been  largely  responsible  for 
procedural  advancements.  The  Tool  Manager  has  prepared  a  "Tool 
Quality  Management  and  Control  Plan”  (301  and  a  "Tool 
installation  Guide"  [311 »  which  together  adress  the  following 
tool-related  issues: 

-  ITooll  selection 

-  Acceptance 

-  Installation  and  maintenance 

-  Configuration  management 

-  New  tool  development 

-  Administration  and  legal  problems 

Improvements  in  the  level  of  tool  support  provided  by  the 
NSw  system  are  much  like  tile  system  improvements  (see  Section 
fc.2.2)  largely  determined  bv  evolution  of  the  various  host  family 
implementations  of  the  Foreman  and  Batch  Job  Package  components: 
progress  in  this  area  is  summarized  below  by  host  family: 

TOPS-20  (Foreman) 

-  Support  tor  allocation  and  archiving  of  tool 
sessions 

-  Improved  tool  session  management,  including  user 
prompts  tor  workspace  tile  access 

•  Simplification  of  operator  interface 

-  improved  reliability  mechanisms 

*  Proposed  protocol  modifications  to  improve 
performance 


Multics  (Foreman) 


More  reliable  and  resilient  implementation 


-  Support  for  aborting  and  rerunning  tool  sessions 

•  support  required  for  the  NS*  reliability  scenarios 

•  Improved  user  interface  and  workspace  management 

•  Support  for  program  execution 
IBM  (foreman,  and  Batch  Job  Package) 

•  improved  operator  support  for  batch  lobs 

•  Full  interactive  tool  support  (excluding  NSW 
reliability  scenarios) 

A  measure  of  tool  support  status  (and  progress  as  well)  mav 
be  gleaned  by: 

-  Identifying  the  new  tools  installed  in  the  NSW  system 
during  the  contract  period  covered  by  this  report 
(Table  b-2) 

•  Summarizing  the  number  of  tools  Installed  on  each  host 
by  "nsw"  tool  type  as  defined  in  Section  6.1.3  (Table 
b-3) 

•  itemizing  nsw  tools  by  name  and  User  System  Host  (Table 
6-4H32J 

-  Itemizing  nsw  tools  by  "generic"  tool  type  and  User 
System  host  (Table  6-5)133) 


v;  frh 
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Jk 


T0PS-20  (5) 


CONCORDANCE 

ECL 

FMTBCPL 

PSAVE 

SRCCOM 

IBM  (24)5 

ASM  bid 

ASMCOMP 

ASMLINK 

COBOL 

COMPRESS 

CREAI’EC 

CHEATtL 

crea'i'eo 

CREATEP 

DISPLAY 

FORTCOMP 

FOKTL1NK 

GETC 

oETO 

GETP 

HBMA1NT 

MERGELlb 

PLICOMP 

PL1 LINK 

PLM80 

PUTC 

PUTO 

PUTP 

T SOEDIT 

MULTICS  (S)J 

ADA 

ADA-LSTA] 

PDL 

RON 

KUN-ADA 


raole  6-2 


New  NSW  Tool  oy  Host 


Family 


1 04 


Management 

NSW 

Batch 

Interactive 

Total 

1SIE 

5 

a 

d 

2d 

25 

1SIC 

d 

a 

d 

21 

21 

RADC-20 

d 

6 

d 

16 

16 

CCN 

d 

a 

rd 

2 

32 

RADC- 

MULTICS 

16 

i 

i 

i 

i  « 

d 

13 

13 

TOTAL 

b 

a 

3d 

72 

107 

Table 

6-3 

Number  ot  NSW  Tools  ov  User  System  Host  sod  "NSW"  Tool  Type 


GENERIC 

m  m  m  m 

HOST  SPECIFIC 

-  - 

NAME 

SUFFIX 

USC- 

USC- 

RADC- 

RADC- 

UCLA- 

1SIE 

IS1C 

20 

MULTICS 

CCN 

ADA 

-RM 

AuA-LSTAT 

-KM 

(library-status) 

ALM 

-RM 

ASM80 

-UC 

a 

ASMCOMP 

-UC 

* 

ASM  LINK 

-UC 

* 

ASST  GNKIGHTS 

(none) 

BASIC 

-RM 

BCPL 

-IE 

-IC 

•R2 

BOOT 

-IE 

-IC 

-R2 

CMS2M 

-UC 

COBOL 

-OC 

COMPRESS 

-UC 

CONCORDANCE 

-IE 

CREATEC 

-UC 

CREATEL 

-UC 

CkLATENODE 

(none) 

CREATEO 

-UC 

CHEATEP 

-UC 

OELETENODE 

(none) 

DESCRIBE 

-IE 

-1C 

-R2 

DISPLAY 

-UC 

ECL 

-IE 

EMLOAD 

-IC 

EXAM INENODE 

(none) 

f  Ml'BCPL 

-IE 

FORTCOMP 

-UC 

a 

FOKTMNK 

-UC 

a 

FORTRAN 

-RM 

-UC 

a 

FTP 

-JE 

-IC 

-R2 

GETC 

-UC 

a 

fable  6-4 


NSw  Tools  by  Name  and  user  systea  Host 
iNote:  Batcn  tools  are  marted  wltn  an  asterisk  ("*")] 


Table  b-4  (continued)* 
GENERIC 
NAME 


HOST  SPECIFIC 
SUFFIX 


USC- 

usc- 

GETO 

GETP 

HELP 

1SIE 

1S1C 

HOSTAT 

-IE 

-xc 

iDDT 

-IE 

-IC 

JIGSAW 

L1BMA1NT 

-IE 

-IC 

LINKER 

-IE 

-IC 

MACRO 

-IE 

-1C 

MACRO20 

MERGEL1B 

-IC 

MRUNOFF 

-IE 

-IC 

NETSTAT 

P')L 

PL1 

PL1 

PlIBGO 

PLICOMP 

PHLINK 

PLM80 

-IE 

-IC 

PRIM 

-IC 

PSAVE 

PUTC 

PUTO 

PUTP 

OEDX 

-IE 

RENOVERIGHTS  (none) 


RADC-  RADC-  UCLA- 

20  MULT1CS  CCN 

-UC  * 
-UC  * 

-RH 

-R2 

-R2 

-R2 

-UC 

-R2 

-R2 

-UC  * 
-UC  * 

-R2 

-R2 

-RM 

-RM 

-UC  * 
-UC  * 
-UC  * 
-UC  * 
-UC  * 


-UC  ♦ 
-UC  * 
-UC  * 

-RM 


Table  6-4 

NSw  Tools  by  Name  and  user  System  Host 
(Note*  Batch  tools  are  marked  with  an  asterisk  ("*")J 


Table  b-4  (continued) 
GENERIC 
NAME 


HOST  SPECIFIC 
SUFFIX 


RUN 

-RM 

KUN-ADA 

-RM 

RUNOFF 

-RM 

SMITE 

SOS 

-IE 

-IC 

-R2 

-RM 

SPELL 

SPPCOBOL 

-IE 

-IC 

-R2 

-RM 

-UC 

SRCCOM 

-IE 

-IC 

-R2 

TECO 

TSOED1T 

-IE 

-IC 

-R2 

-UC 

UVK20 

-IC 

XEO 

-IE 

-IC 

-R2 

Table  6-4 


nsw  Tools  by  Nave  and  User  System  Host 
(Note:  Batch  tools  are  marked  with  an  asterisk  (**”)] 


TK Pfc  OF 
TOOL 


GENERIC 

NAME 


HOST  SPECIFIC 
SUFFIX 


usc- 

usc- 

RADC- 

RADC- 

UCLA- 

1SIE 

1S1C 

29 

MULIICS 

CCN 

assembler: 

ALM 

-RM 

asmcomp 

-uc 

* 

MACRO 

-IE  -1C 

-R2 

compiler: 

ADA 

-RM 

BASIC 

-RM 

BCPL 

-IE  -IC 

-R2 

COBOL 

-uc 

a 

FOKTCOMP 

-uc 

a 

FORTRAN 

-RM 

-uc 

a 

PL1 

-RM 

PL1 

-uc 

a 

PLIBGO 

-uc 

a 

PLICOMP 

-uc 

a 

SMITE 

-RM 

SPPCOBOL 

-uc 

a 

CROSS  ASSEMBLER: 

ASM80 

-uc 

a 

MACRO20 

-IC 

-uc 

a 

CROSS  COMPILER: 

CMS2M 

-uc 

a 

PLM80 

-uc 

a 

DEBUGGER: 

BOOT 

-IE  -IC 

-R2 

IOOT 

-IE  -IC 

-R2 

Table  6-5 

NS«t  Tools  oy 

Generic  Tool  Type 

and  User 

Systea 

Most 

(Note:  Baton 

tools  are  marked 

wltn  an 

asterisk 

Table  t-b  (contlnue.l) t 


TYPE  OF 

GENERIC 

•  a»  • 

HOST 

SPECIFIC  -  -  1 

TOOL 

name 

SUFFIX  | 

X 

EDITOR: 

OEOX 

SOS 

-IE 

-IC 

-R2 

i 

TECO 

-IE 

-IC 

-R2 

f 

TSOE01T 

XED 

-IE 

-IC 

-R2 

•UC  I 

f 

EXECUTION 

SUPPORT 

* 

RUN 

-RM 

KUN-ADA 

-RM 

FILE  UTILITY! 

DISPLAY 

FTP 

-IE 

-IC 

-R2 

-UC 

SHCCOM 

-IE 

-1C 

-R2 

i 

INTERPRET fcRi 


ECL 

PLIBGO 


jIBRARY  UTILITY; 

AUA-LSTAT 

COMPRESS 

CREATEC 

CREATEL 

CKEATEO 

CREATE? 

GETC 

GETO 

GETP 

L1BMA1NT 

MEKGEL1B 

PUTC 

PUTO 

PUTP 


Table  6-5 

NS*  Tools  by  Generic  Tool  Type  and  User  systee  Host 
(Note:  Batch  Tools  are  Marked  «ith  an  asterisk  ("*■)) 


Table  6-5  (continued) 


TYPE  OF  GENERIC 

TOOL  NAME 

•  m 

*  1 

HOST  SPECIFIC 
SUFFIX 

SYSTEM  INFOS 

OESCR1BE 

HELP 

-IE 

-IC 

-R2 

-RM 

HOSTAT 

-IE 

-IC 

-R2 

NETSTAT 

-IE 

-IC 

-R2 

TEXT  PROCESSORS 

MRUNOFF 

RUNOFF 

-IE 

-IC 

•R2 

-RM 

Table  6*5 

NSN  Tools  by  "Generic11  Tool  Type  and  User  Systea  Host 
(Notes  Batch  tools  era  Marked  with  an  asterisk  ("*")l 


6.2.4  User  Documentation 

At  different  times  in  the  prolect's  history,  various  nsw 
user  oriented  documents  have  been  prepared.  These  include: 

-  "Tne  nsw  Users*  Reference  manual"  (351 

-  "The  nsw  Users*  Guide"  1361. 

-  "Interim  NSw  Managers*  Tools"  (371 

-  "The  nsw  Beginners*  Guide”  l 3S j 

Currently,  the  only  docuaent  that  is  maintained  updated  is  the 
"nsw  user's  Reference  Manual".  GSG  updates  this  document  for 
each  new  system  release.  GSG  was  also  tasKed  with  preparation  of 
an  "NSk  user  Impact  Bulletin"  for  each  NSw  system  release. 

The  "nsw  user  impact  Bulletin"  (381  augments  the  "NSw  Users* 
Reference  Manual".  The  Bulletin  was  designed  to  oe  a  highly 
modular  compendium  of  notes: 

-  identifying  all  user  visible  changes  associated  with  a 
new  system  release.  These  changes  can  take  many  forms, 
including  new  or  changed  command  functionality, 
elimination  of  bugs  found  in  earlier  releases,  improved 
error  messages,  and  new  tools,  implementation  or  nost 
facilities. 

-  identifying  all  known  user  issues  and  limitations  that 
exist  in  the  current  release,  and  suggesting  how  to 
respond  to  each. 

-  augmenting  existing  NSW  user  documents  as  needed.  For 
example,  the  U1B  attempts  to  clarify,  expand,  and 
provide  additional  background  on  user  features  that  mav 
be  misunderstood  or  are  counter*intuiti ve  in  tnelr 
application. 

•  supplementing  the  nsw  user  documentation  by  supplying 
Information  not  otherwise  available.  For  example,  the 
uib  comprises  the  only  uniform  documentation  of 
operational  differences  between  tools  in  the  nsw 
environment  and  their  behavior  in  the  native  host 
environment  (with  the  possible  exception  of  UCLA  tool 
documentation  ••  see  below). 

Items  whicn  fall  into  the  above  categories  are  typically 
presented  as  incremental  updates  relative  to  tne  last  NSw  system 
release.  Such  items  are  generally  removed  from  the  "User  Impact 
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Bulletin”  within  the  next  two  NSW  system  releases.  However,  some 
Items  remain  in  the  "user  Impact  Bulletin”  until  they  are 
incorporated  into  more  suitable  user  documentation  (e.g.,  the 
”NSW  Users'  Reference  manual”).  With  the  above  requirements  in 
mind,  the  "User  Impact  Bulletin”  was  desiqned  so  that  Incremental 
modifications  could  be  made  easily  and  quickly. 

"User  Impact  Bulletins”  have  been  prepared  and  distributed 
for  nsw  releases  4.1  and  5.0  (39,49).  In  addition,  a  "special" 
version  of  the  "User  impact  Bulletin"  for  NSW  4.1  (411, 
containing  only  tnose  items  to  be  considered  as  candidates  for 
Inclusion  in  the  "Nsw  Users*  Reference  Manual”,  was  prepared  for 
ACC.  Preparation  and  distribution  of  updates  to  the  nsw  4.1 
"User  Impact  Bulletin"  (42)  was  testimony  to  viability  of  tne 
plan  tor  quick,  incremental  modification  of  the  "User  impact 
Bulletin".  After  the  "User  Impact  Bulletin”  for  NSW  4.1  had  been 
completed,  a  plan  tor  maintaining  the  "User  impact  Bulletin"  was 
prepared  and  distributed  to  interested  parties  (43). 

During  development  of  the  "User  Impact  Bulletin”,  GSG 
conducted  a  review  of  tne  existinq  NSW  user  documentation  (44). 
Based  in  part  on  this  review,  user  documentation  requiements  were 
identified  and  documented.  These  requirements  were  then  compared 
to  the  current  state  of  NSW  user  documentation,  and  specific 
tasks  were  proposed  to  address  known  deficiencies  (45) • 

In  tne  separate  area  of  nsw  tool  documentation  (describing 
operability  of  individual  tools  which  have  been  installed  In  tne 
NSW  environment),  UCLA  nas  provided  documentation  for  tne 
following  IBM  tools  installed  in  NSW. 


-  "usinq  The  UCLA  Native  Lanquage  Processing  Tool 
Kits"  I4bi 

-  "USlnq  The  01SPLAY  Tool"  (47) 

-  "Using  The  TS0ED1T  Tool"  (48) 

-  "using  tne  UCLA  PL/I  Tool  Kit"  (49) 

*  "using  The  UCLA  Interim  Library  Management  Tool 
Kit"  150] 


6.2.S  future  Directions  and  Problem  Areas 


probably  tne  most  important  development  planning  that 
occurred  aurinq  the  contract  period  covered  by  this  report  has 
been: 


•  Formulation  of  the  functional  and  performance 
attributes  required  for  the  AFLC  Technology 
Demonstration, 

•  Recognition  of  NSW  structural,  performance  and  feature 
deficiencies  relative  to  Demonstration  needs,  and 

-  Preparation  of  a  development  plan  for  addressing 
Technology  Demonstration  support. 

Durinq  the  latter  half  of  the  contract  period,  an  NS*  Analysis 
Group  (chaired  oy  Bob  Thomas  of  BBN)  was  created.  This  internal 
group  was  assigned  the  following  tastes: 

•  Identify  NS*  requirements  (for  the  AFLC  Technology 
Demonstration) 

-  Prepare  a  functional  specif icatlon  which  conforms  to 
the  identified  requirements 

•  Develop  an  evolution  plan  for  realising  the  specified 
nsw  functions 

Based  on  input  from  NS*  users  and  contractors,  the  Analysis 
Group  identified  and  documented  NS*  requirements  in  a  document 
referred  to  as  tne  "NSW  Concept  Paper"  151).  GSG  also  proposed 
requirements  (52)  and  reviewed  the  requirements  distributed  by 
the  ns*  Analysis  Group  (5i).  Subsequently,  the  Analysis  Group 
prepared  a  revised  NSW  Functional  Specification  (54).  This  plan 
will  serve  as  a  guideline  for  NSW  development  activities  during 
the  Technology  Demonstration  period.  A  summary  of  NSW  system 
areas  likely  to  receive  attention,  and  examples  of  proposed 
improvements  follow: 

-  user  Interface 

.  User  1/0  commands  (e.q.,  display  contents  of  a  file 
on  the  user's  terminal) 

•  User  information  and  status  reporting  commands  (e.q., 
system  status,  file  attributes,  etc.) 
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Improved  error  reporting  (e.g.,  report  abnormal 
conditions  to  the  NS*  fault  Loqger) 

Simplified  User  Model 

Single,  uniform  namespace  for  files  and  tools 
(executable  programs) 

Tool  Support 

Tool  chaining  (e.g.,  compile,  then  link,  then  load 
and  execute  by  invoking  one  rather  than  three  tools) 

User  "owned”  workspaces 

file  System 

User  "owned"  segments  of  NSw  filespace 
Improved  file  translation  and  tvplnq 
Additional  file  access  methods  (e.q.,  direct  access) 
Reliable  transfer  of  long  files 
Performance 

Optimized  file  motion  and  access  protocols 

Support  for  "native"  services  (i.e.f  tools  and 
servers  which  operate  in  port  "outside"  of  NSW,  in 
the  "native"  host  environment) 


6.2.6  NSW  Availability 


NSW  System  Operations  (nswops)  is  responsible  for  ooeratinq 
the  NSW  user  System  configuration  on  behalf  of  tne  NSW  user 
community.  A  goal  of  GSG's  nsw  operations  group  has  been  to 
achieve  maximum  NSW  availability  durinq  operator  attended  periods 
(9  am  •  5  Pm  EST,  Monday  -  Friday).  This  means  tnat  NS#  system 
downtime  should  correlate  as  closely  as  possible  to  tne  duration 
of  nsw  host  outages  (especially  the  "Core  System"  host  *•  see 
Section  4.4.3). 

To  provide  a  measure  of  service  provided  by  NSWOPS  to  the 
NSw  user  community,  aggregate  statistics  ot  ns#  availability  for 
the  period  October  8.  1979  through  November  10.  1981  are 
summarized  below: 


Average  weetclv  Downtime 
(nours  6  minutes) 

NSw  Availability  (%) 


lime  Period 


Operator 

Attended 

only 


Operator 
Attended  and 
Unattended 


(*-F,  9-5) 


(M-F,  All  Dav) 


3:38  44:02 

91%  74% 


Tne  above  figures  are  saved  on  "Core  System"  availability 
statistics  accumulated  since  October  of  1979.  (Note:  nsw  can 
continue  to  operate  in  tne  tace  ot  some  non-"Core  System"  host 
outaqes;  however,  the  nsw  system  remains  completely  unavailable 
to  users  during  "Core  System"  Host  outaqes.) 
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7.0  NSW  System  Operations 

During  197b,  an  NSw  Operations  Office  (NSwOPS)  was 
estabiisned  at  tne  Rome  Air  Development  Center,  Srlftiss  Air 
Force  Base,  Rome,  New  York.  Since  tnat  time,  on-site  GSG  staff 
members  have  Deen  expanding  and  evolvina  tne  NSW  Operations 
Center  wnicn  is  responsible  for  tne  NSW  User  System.  NSWOPS 
tasks  and  responsibilities  are  reviewed  in  tne  first  section 
wnicn  follows.  Ine  second  section  discusses  NSwOPS  activities 
and  contributions  during  the  contract  report  covered  by  this 
period. 
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7.1  NSwOPS  Responsibilities 


Tne  major  responsibilities  of  tne  nsw  Operations  are 
summarized  below: 

1.  Install  and  operate  NSW  system  releases  in  the  nsw 
user  System  conf iouration 

2.  Devise  and  automate  operational  procedures;  apply 
these  (.automated)  procedures  to  tne  NS«  User  and 
Candidate  System  configurations. 

3.  Provide  technical  support  to  the  NSW  user  community, 
assuring  expeditious  resolution  of  all  user  questions 
and  proolems;  develop  an  accounting  system  for 
tracxinq  all  user  inquiries  and  Software  Trouble 
keports  (STR's). 

4.  Provide  user  information  services  including  an  nsw 
HELP  facility  and  usaqe  reporting  for  tne  NSw 
operations  dataoase. 

5.  Prepare  NSw  user  documentation  including  a  "User 
Impact  bulletin”  summarizing  pertinent  information 
tor  use  of  the  nsw  system  and  its  tools,  including: 
Improvements,  outstanding  ougs,  limitations, 
anomolies  and  procedures  for  dealing  with  and/or 
circumventing  tnese. 

6.  implement  configuration  control  and  audltinq 
procedures  in  tne  nsw  User  System  configuration. 
Maintain  the  ns*  Documentation  Repository,  placing 
nsw  documentation  under  configuration  control 

7.  Support  PDC  Quality  Assurance  (U/A)  activities  by 
operating  tne  nsw  Candidate  System  and  participating 
in  o/a  testing  under  PDC's  direction. 

A  more  detailed  discussion  of  nswops  activities  and  achievements 
may  be  found  in  the  Section  (7.2)  which  follows. 
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7.2  NSwOPS  Activities  and  Accomplishments 

The  major  accomplishments  and  contributions  ot  the  N sw 
Operations  organization  (NSwOPS),  in  each  major  area  ot 
responsibility  (see  Section  ?.i)  are  summarized  below: 

1.  User  System  Operations 

This  task  primarily  concerns  the  application  of 
(automated)  operational  procedures  (see  2  below)  to 
operation  of  the  NSW  user  Systea  configuration. 

Due  to  autonomous  operational  requirements  of  the  IBM 
and  Multlcs  hosts,  the  scope  of  nswops*  operational 
activities  is  limited  to  the  set  of  TOP6-20  ARPANET 
hosts  participating  in  the  User  System  configuration. 
The  IBM  and  Multlcs  hosts  operate  primarily  in  an 
"autostart”  mode;  little  it  any  operator  intervention 
is  ever  required  (except,  possibly  to  track-down 
bugs). 

The  set  of  participating  TOPS-20  hosts  must,  of 
necessity.  Include  the  "Core  system”  Host.  Most  of 
the  operational  requirements  imposed  by  the  NS* 
system  are  focused  on  this  "Core  System”  host,  where 
control  and  synchronization  are  centralized  and  the 
critical  system  databases  (user,  file  and  tool 
catalogs)  are  maintained. 

nswops  strives  to  achieve  maximum  systea  availability 
for  the  NSW  user  community.  NSWOPS  has  been  very 
successful  in  meeting  this  self-imposed  goal  (see 
section  6.2.6  for  details). 

2.  nsw  Operations  Procedures 

NSWOPS  is  tasked  with  development  ot  manual  and 
automated  procedures  for  operating  NSW  systea 
configurations.  Due  to  the  nature  of  tne  operator 
interface,  procedures  for  operating  NSW  systeas  tend 
to  be  many,  varied  and  complex,  in  spite  of  this, 
much  has  been  achieved  during  the  contract  period  in 
the  areas  of  procedure  development  and  automation. 

nsw  operators  must,  minimally,  be  concerned  with 
procedures  for: 
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•  installing  new  nsw  system  releases*  and 

-  operating  installed  releases 

Development  and  documentation  o t  a  "kernel"  set  of 
operations  procedures  for  release  installation  and 
operation*  a  significant  undertaxing*  was  completed 
during  the  contract  period  covered  by  this  report  [551. 
In  addition*  the  following  procedures  were  partially  or 
completely  automated: 

•  Installation  of  new  NSw  system  releases 

-  Recognition  ot: 

nsw  failures 

nsw  ARPANET  host  outages 
Restoration  ot  nost  service 

•  Operator  notification  of  nost  failures  and 
restarts 

-  Host  clean-up  and  restart 

user  Support  and  Technical  Assistance 

nswops  is  logically  [and  has  officially  been 
designated)  the  focal  point  for  resolution  ot  user 
questions  and  problems.  In  support  of  this 
responsibility*  NSWOPS  was  tasked  with  the 
development  of  a  Software  Trouble  Report  accounting 
system  which  could  be  used  to  track  outstanding  user 
questions*  bug  reports  and  new  feature  requests  (as 
well  as  contractor-reported  bugs  and  deficiencies). 

GSG  designed  and  implemented  a  highly  parametric  and 
flexible  accounting  system  based  on  the  existing 
Arpanet  mail  facility.  However*  after: 

-  Considerable  experience  had  been  gained  with  the 
mail-based  system*  and 

-  Volume  had  increased  dramatically*  and 

-  Requirements  for  controlled  interaction  between 
nsw  users  became  apparent* 

A  protocol-oriented  tool  for  MONitorlng  STR*s  (MONSTR) 
was  conceived*  designed  and  implemented  by 
Massachusetts  Computer  Associates  (COMPASS).  For  more 
on  STR  processing*  see  Section  5.5. 


4.  user  Information  Services 


NSWOPS  serves  as  a  conscientious#  accurate  source  of 
information  about  NS*  system  features  status  and  use. 
NSwOPS  nas  been  responsible  tor  developing  a  number 
of  venicies  tor  communicating  information  to  ns* 
users: 

-  Periodic  usage  reporting 

•  Automated  status  reporting 

•  An  integrated#  user-oriented  information  utility 
(HELP  facility) 

-  Tne  "ns*  User  impact  Bulletin"  (see  5  belo«  or 
Section  6.2.4) 

.  At  tne  beginning  of  eacn  week,  nswops  prepares# 
publishes  and  distributes  a  report  detailing 
availability  and  utilization  of  tne  nsw  User  System  for 
tne  preceeding  week.  A  sample  "weeiclv  Usage  Report” 
appears  in  Appendix  0. 

System  status  reporting  is  an  integral  part  of  tne 
automated  host  failure  and  restart  recognition  process 
(see  2  aoove).  Users  may  query  current  system  status 
information  (maintained  by  this  automated  operator 
utility)  through  a  special  IOPS-23  command  at  RADC-20 
or  tne  ns*  HELP  facility  (see  below). 

NSWOPS  was  tasked  with  development  of  an  ns*  HELP 
facility  for  tne  NSW  user  community.  First#  a 
specification  detailing: 

•  Information  requirements 

-  Functional  requirements 

-  user  interface 

.  was  prepared  for  review  (56).  At  tnis  stage  it  became 
apparent  that  ambitious  requirements  could  be  realized 
through  a  facility#  of  great  generality  and  power# 
which  could  also  be  constructed  at  a  very  reasonable 
cost.  Tne  product  of  this  effort  is  a  nloh-qualltv # 
integrated  information  utility  which: 

-  Provides  a  uniform  interface  to  wide  variety  of 
information 
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•  Allows  information  to  os  adds*  or  exchanged 
without  modifying  software 

-  Provides  an  easily  extended  topical  index*  and 

-  is  user-oriented  and  friendly 

.  This  facility#  available  as  an  nsw  tool#  provides  NSw 
users  with  on-line#  interactive  access  to  the  following 
information: 

•  "NSw  User  lapact  Bulletin" 

-  "NSw  Users*  Reference  Manual" 

-  "interim  NSw  Managers*  Tools" 

-  "NSw  Documentation  Summary” 

-  DESCRIBE  Tool  databases 

-  help-km  tool  databases 

-  Current  NSW  system  status  (as  described  above) 

.  in  addition,  the  HELP  Facility  provides  a  netmail 
conduit  between  NSw  users  and  NSWOPS#  It  has  been 
provided  so  that  nsw  users  may  send  written 
communications  to  NSWOPS  from  within  NSw.  Among  other 
things*  this  provides  NSW  users  witn  a  mechanism* 
internal  to  nsw,  for  Initiating  inquiries  and  Software 
Trouble  Reports  (see  3  above)#  we  refer  Interested 
readers  to  Appendix  C  which  provides  a  tnorougn 
overview  of  the  nsw  HELP  facility  —  its  goals* 
functions  and  information. 

5.  user  Documentation 

Tne  "User  Impact  Bulletin"  is  NSWOPS*  major 
responsibility  in  tne  area  of  user  documentation.  In 
addition,  nswops  has  shown  a  conscientious  interest 
in  understanding  and  responding  to  user  documentation 
needs,  we  refer  tne  reader  to  Section  6.2.4  where 
both  of  these  items  are  discussed  in  detail. 

6.  Configuration  Management 

Configuration  management  is  an  integral  part  of 
managing  the  nsw  software  development  process  (see 
section  5.6) •  nswops  is  responsible  tor  implementing 
configuration  management  procedures  devised  by  PDC  in 
tne  nsw  user  System  configuration,  nswops  controls 
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changes  to  (l.e.,  the  Introduction  of  nee 
configuration  itees  into)  tne  NSW  User  Svstea 
configuration  and  performs  periodic  audits  to  verify 
conformance  with  the  baseline  configuration  (this  is 
most  important  for  the  IBM  and  Multics  nost 
configurations  wnlch  are  not  directly  under  NSWOPS* 
operational  control).  In  addition.  NSWOPS  is 
responsible  tor  controlling  and  auditing  changes  to 
the  NSw  Documentation  Repository,  which  is  the  focal 
point  tor  collection  and  dissemination  of  all  nsw 
documentation.  Procedures  tor  maintaining  the  nsw 
Documentation  Repository  nave  oeen  devised  and 
partially  automated  (571.  These  procedures 
automatically: 

-  Update  an  index  of  documentation  repository 
contents,  and 

•  Generate  a  formatted  "NSw  Documentation  Summary" 
which  is  oublicallv  available  to  interested  nSw 
contractors  and/or  users 

.  The  Documentation  Repository  index  is  in  a  format 
compatible  with  and  accessible  througn  tne  NSm  help 
facility  (see  4  above). 

7.  O/A  Testing  Support 

nsmOPS  supports  PDC*s  0/A  testing  activities  in  a 
number  of  ways: 

-  Operation  of  the  NSW  Candidate  System  during  0/A 
assessment  periods 

•  Assistance  in  preparation  and/or  modification  of 
test  plans,  methodologies  and  scripts 

-  Application  of  tests  to  new  NSW  system  releases 

-  Assistance  in  preparation  of  test  scenarios  and 
reports 

.  O/A  assessment  activities  are  very  much  a  joint  effort 
between  PDC  and  nswops.  It  is.  therefore,  not  easy  to 
distinguish  the  specific  responsibilities  (other  than 
Candidate  system  operation)  of  one  organisational 
entity  from  the  otner.  We  refer  tne  reader  to  Section 
5.4  for  a  more  detailed  discussion  of  SSG's  (PDC  and 
nswops)  Quality  Assurance  activities. 
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8.0  AFLC  Technology  Demonstration 

GSG  (PDC)  has  played  a  major  role  in  the  planning  and 
development  of  the  nsw  AFLC  Technology  Demonstration.  PDC  has 
contributed  directly  to  the  demonstration  planning  activities 
throuqn  participation  in  the  "nsw  working  Group”  created  for  that 
purpose.  At  RADC *s  request,  technology  transfer  [561  and 
demonstration  milestone  (591  plans  were  proposed  tor  the 
demonstration. 

Early  in  the  planning  stages,  the  NSW  working  Group 
concentrated  on  identifying  and  developing  application  scenarios 
for  the  technology  demonstration.  GSG  proposed  a  procedure  for 
the  identification  and  development  of  these  application  scenarios 
1601 . 

The  following  four  application  areas  were  identified  by  the 
participating  AFLC  sites  as  candidate  demonstration  scenarios: 

1.  Configuration  Management 

2.  Lmulation  Support 

3.  nsw  Tool  Repository 

4.  ADA  Training 

Configuration  Management  was  selected  by  tne  AFLC's  as  the 
demonstration  scenario  which  should  receive  highest  priority. 

GSG  was  assigned  responsibility  for  coordinating  and  developlna 
the  Configuration  Management  scenario.  GSG  responded  by 
developing  a  general  multi-level  approach  to  development  of  the 
CM  scenario  [611.  and  oy  proposing  a  specific  tool-based  approach 
for  implementing  the  scenario  [621. 

Tne  future  requires  further  refinement  and  development  of 
the  approach  for  the  Configuration  Management  scenario  which  will 
be  achieved  by: 

-  working  with  participating  AFLC's  to  identify 
requirements 

-  Preparing  a  suitable  NSW-based  CM  capability 

-  Testing  the  Nsw-based  CM  capability  prior  to 
demonstration,  and 

•  Supporting  AFLC  use  of  tne  CM  capability  during  the 
demonstretlon  period. 
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S  VI 


Appendix  H:  Generic  Configuration  Items 


inis  appendix  is  desiqned  to  complement  tne  discussion  of 
ns*  "Configuration  Management"  which  appears  in  Section  5.6  of 
this  report. 

In  the  three  (3)  subsections  which  follow,  this  appendix 
ummarizes  the  decomposition  methodology  used  to  identify 
generic  configuration  items"  and  enumerates  tne  current  set  ot 
generic  Cl's  for  each  of  the  following  "pacxets": 

-  NSW  system  packet 

•  TOPS-20  Host  Family  packet.  Due  to  the 

autonomous  operational  requirements  of  the  lbM 
and  Multlcs  ns*  hosts,  the  set  of  "packets" 
covered  by  this  appendix  excludes  the  Host 
Family  packets  tor  these  host  families. 
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B . 1  Generic  Configuration  Items  (Cls) 


The  set  ot  generic  Cls  for  the  ns*  System  consists  ot  tne 
following  two  (sets  of)  "packets": 

X.  The  "nsw  System  Packet",  identifying  the  Cls  generic 
to  the  (entire)  nsn  system*  consists  of  the  following 
three  items: 

(1)  System  databases  list 

(2)  Operator  aids  list 

(i)  System  documentation  lists*  one  for  each  of 
the  following  sets  ot  documentation: 

(A)  Host-independent  functional 
soecif icatlons 

(b)  Release  documentation 

(C)  User  documentation 

(D)  Operations  documentation 

II.  (A  set  of)  "Host  Family  Packets”*  identifying  the  Cls 
tor  each  host  family  implementation  ot  NSw 
functionality*  consists  ot  the  following  three  (sets 
ot)  pacxets: 

1.  A  "Generic  Host  Packet"*  identifying  the  Cls 
common  to  one  or  more  nost  components  (see 
"Component  Packets"  below)*  consists  of  the 
following  four  items: 

(1)  Databases  list 

(2)  utility  executables  list 

(3)  operator  aids  list 

(4)  Documentation  list 

2.  (A  set  ot)  "Component  Packets",  identifying  the 
Cls  tor  each  nost-soeclf lc  component  ot  NSN 
functionality*  consists  of  the  following  five 
items: 
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(1)  Component  executables  list 


(2)  Component  databases  list 

(3)  Utility  executables  list 

(4)  Operator  aids  list 

(5)  Documentation  list 

3.  [A  set  otl  "Tool  Packets",  identifying  the  CIs 
tor  each  ns*  tool  of  tne  host  family,  consists 
of  the  following  four  items: 


(1) 

Tool  executables  list 

(2) 

Tool  databases 

list 

C  3  ) 

Operator  aids 

list 

(4) 

Documentation 

list 

Tne  qeneric  CIs  for  tne  "NS*  System"  and  tne  TOPS-2B  Host 
Family  "packets"  are  enumerated  in  subsections  B.2  and  B.3  which 
follow. 
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B.2  nsw  System  Packet 


The  nsw  system  packet  contains  the  following  (sets  of) 
generic  configuration  items: 


(1)  System  Database(s);  CONFIG. BAS  (A)  (Universal 
Configuration  Database  (UCO)l 

(2)  Operator  Aid(s):  none  ('none*  *  no  configuration 
ltem(s)  to  be  CONTROLLED) 

(i)  System  Documentation: 

(A)  Functional  specifications 

(1)  "NSW  Functional  Specification"  (A) 

l 'A*  *  an  up-to-date  revision  to  be 
supplied  bv  the  Architecture  Control 
Contractor  (ACC)  during  release 
transition  to  the  Product  Development 
Contractor  (PDC)). 

(2)  "Svstem/Subsystem  Specification"  for 
each  of  tne  following  generic 
functional  components: 

-  Batch  Job  Package  (A) 

-  Checkpolnter  (A) 

-  Dispatcher  (A) 

-  Front  End  (A) 

-  Fault  Logger  (A) 

-  Foreman  (A) 

-  File  Package  (A) 

-  MSG  (A) 

•  Operator  utility  (A) 

•  works  Manager  (A) 
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Words  Manager  operator  (A) 


(3)  "Universal  Configuration  Database 
(UCD)  Specification"  (A) 

CB)  Release  Documentation 

(1)  "Release-Specific  Documentation* 
icovering  all  nost  (family) 
implementations)  (A) 

(C)  User  Documentation 

(1)  "NSW  Beginners*  Guide*  (P4)  l*P*  *  an 
up-to-date  revision  to  oe  supplied  py 
PDCj  *4*  *  an  uo-to-date  revision  to 
be  supplied  shortly  after  release 
transition  from  PDC  to  tne  ns*  user 
communitv) • 

(2)  "ns*  users*  Reference  Manual" 
(revisions  tor  ootn  tne  TKNf.x/TOPS-20 
and  Unix  Front  Ends)  (A) 

(3)  "ns*  users*  Guide"  (A) 

(4)  "interim  NSw  Manager's  Tools"  (until 
Incorporated  in  tne  "nsn  user's 
Reference  Manual")  (A) 

(5)  "user  impact  Bulletin"  (DO  (*D*  * 
up-to-date  revision  to  be  supplied  by 
nsw  Operations  (nswopS)) 

(D)  Operations  Documentation 

(1)  "NSw  installation  Guide"  (A) 

(2)  "NS*  Operations  Guide"  (04) 
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B.3  TOPS-20  Host  Family  PacKet 


Tne  TOP5-20  Host  Family  packet  includes  the  following 
(sets  of)  generic  Cl  packets: 

1.  rENtx/TOPS-20  Generic  Host  Packet: 

(1)  Database(s):  none 

(2)  Utility  Executable(s):  LOGUTL.EXE  (A) 

(3)  Operator  Aid(s):  none 

(4)  Documentation:  none 

2.  TENEX/TOPS-20  Component  Packet (s): 

ChecKpolnter : 

(1)  Component  Executablets ) :  CHKPTR.EXE  (A) 

(2)  Dataoase(s):  none 

(3)  utilities:  none 

(4)  Operator  Ald(s):  none 

(5)  Documentation: 

•  Interface  Conformance  Report(s):  (A) 

•  Program  Maintenance  Manual(s):  (A*) 

-  Operator  rtanual(s):  (A) 

uispatcner : 

(1)  Component  Executablets ) :  OSPCHR.exe  (A)  and 
NSWROOT.EXE  (A) 

(2)  Dataoase(s):  none 

(3)  utilities:  none 


(4)  Operator  Ald(s):  none 

(5)  Documentation: 

-  interface  Conforaance  Report(s):  (A) 

•  Program  Maintenance  Manuai(s):  (At) 

-  Operator  Manuai(s):  (A) 

Front  End: 

(1)  Component  Executable(s):  Fe.EXE  (A), 
FETHDL.EXE  (A)  and  UNTLNT.EXE  (A) 

(2)  Dataoase(s):  none 

(3)  utilities:  none 

(4)  Operator  Ald(s):  none 

(5)  Documentation: 

-  interface  Conformance  Report(s):  (A) 

-  Program  Maintenance  Manuai(s):  (At) 

•  operator  Manual(s):  (A) 

Fault  Logger 

U)  Component  Executabie(s):  FL.EXE  (A) 

(2)  Database(s):  none 

(3)  utilities:  FLTEST.EXE  (A)  and  FLOPER.EXE 

(A) 

(4)  Operator  Aid(s):  none 

(5)  Documentation: 


Interface  Conforaance  Report(s):  (A) 
Program  Maintenance  Manual(s):  (At) 
operator  Manuai(s):  (A) 


Hie  package 

(1)  Component  Executable(s):  FLPKG.EXE  (A) 

(2)  Dataoase(s):  none 

(3)  Utilities!  none 

(4)  Operator  Aid(s):  none 

(5)  Documentation: 

-  Interface  Conformance  Report(s):  (A) 

•  Program  Maintenance  Kanual(s):  IA+) 

•  Operator  Manual(s):  (A) 

Foreman 

(1)  Component  ExecutableCs) :  fOREMAN.EXE  (A) 

(2)  Database(s):  none 

(3)  Utilities:  MKC0M.EXE  (A),  LOGRED.EXE  (A) 

(4)  Operator  Aid(s):  none 
C5 )  Documentation: 

•  Interface  Conformance  Report(s):  (A) 

-  Program  Maintenance  Manual(s):  (A*) 

•  Operator  ManuaiCs):  (A) 

MSG 

(1)  Component  Executabie(s):  MSG. EXE  (A) 

(2)  Database(s) :  MSG-GENERIC--NAMES  (A). 
MSG*N£TNORK*COA FIGURATION  (A) 

(3)  utilities:  none 

(4)  operator  Aid(s):  none 


14* 


C  5 )  Documentation! 


•  Interface  Conformance  Report(s):  (A) 

•  Program  Maintenance  Manual(s):  (At) 

•  Operator  Manual(s):  (A) 


Operator  Utility: 

(!)  Component  Executable(s ) :  OPRUTL.EXE  (A) 

(2)  Database(s):  none 

(3)  utilities:  none 

(4)  Operator  Aid(s):  none 

(5)  Documentation: 

-  Interface  Conformance  Report(s):  (A) 
*  Program  Maintenance  Manual(s):  (At) 

-  Operator  Manual(s):  (A) 


NorKs  Manager: 

(1)  Component  Executable(s) :  '  mm. EXE  (A) 

(2)  Dataoase(s):  mm-on LINE. TABLES  (skeleton) 
(A).  DBMTF.l  (skeleton)  (A),  DBFCE.l 
[skeleton]  (A) 

(3)  Utilities:  SIMNMT.EXE  (A).  SlMNTt.EXE  (A). 
S1M1NF.EXE  (A).  DMPUTL.EXE  (A),  DBSTAT.EXE 
(A).  TBLTRN.EXE  (A)  [Note:  Database 
conversion  procedures  shoul *  be  Included  in 
the  "nsw  Installation  Guide  (see  "System 
Documentation  Packet”)) 

(4)  Operator  Aid(s):  DO  files  for  creating: 

-  The  Checkpolnter  Control  Entry  in  the 
•forks  Manager  Database 

-  Database  skeletons  for  nm*0NLINE. TABLES, 
DBWTF.l  and  DBFCE.l 
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(5)  Documentation: 


*  interlace  Conformance  Reoort(s):  (A) 

•  Program  Maintenance  Manual(s):  (At) 

-  operator  Manual(s):  (A) 

works  Manager  operator: 

(1)  Component  Executable  Is ) :  wMO.EXE  (A) 

(2)  Dataoase(s):  none 

(3)  Utilities:  wMOUIL.EXE  (A) 

(4)  Operator  Aid(s):  none 

15)  Documentation: 

*  Interface  Conformance  Report(s):  (A) 

•  Program  Maintenance  Manuai(s):  (A*) 

-  operator  Manualls):  CA) 

3.  ienex/tops-20  Tool  packetts): 

bCPL: 

(1)  Tool  Executaoie(s) :  dCfL.EXE  ( T )  C*T*  *  an 
up-to-date  revision  to  oe  supplied  ov  the 
nsw  Tool  Manaqer) 

(2)  Database(s):  to  be  identified 

(3)  Operator  Aid(s):  DO  tiles  for  creating  tool 
and  global  tile  descriptor  entries  in  the 
works  Manaqer  database 

(4)  Documentation: 

-  installation:  to  be  identified 

-  Nsw-specif ic:  to  oe  identified 
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Native  Host:  to  oe  identified 


boot: 

(1)  Tool  Executaole(s):  BOOT. EXE  (T) 

(2)  Dataoase(s):  to  oe  identified 

(3)  Operator  Aid(s):  DO  tiles  for  creatin']  tool 
and  global  tile  descriptor  entries  in  the 
Nortcs  Manager  database 

(4)  Documentation: 

-  Installation:  to  be  identified 

-  NSit-specif ic:  to  be  identified 

•  Native  Host:  to  be  identified 

concordance: 

Cl)  Tool  Executaole(s):  CONCOROANCE.exe  (T) 

(2)  Dataoase(s):  to  be  identified 

(3)  Operator  Aid(s):  DO  files  for  creating  tool 
and  global  file  descriptor  entries  in  tne 
tforics  Manager  database 

C  4 )  Documentation: 

•  Installation:  to  De  identified 

•  NSx-Specif ic:  to  be  identified 

•  Native  Host:  to  be  identified 
describe: 

(1)  Tool  Executaoie(s):  OESCRIBE.EXE  (T) 

(2)  Database(s):  to  be  identified 

C3)  Operator  Aid(s):  DO  files  for  creating  tool 
and  global  file  descriptor  entries  in  tne 
mores  Manager  database 
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(4)  Documentation 


•  Installation:  to  be  identities 

-  NSW-Specif ic:  to  be  identified 

-  Native  Host:  to  be  identified 

CCL: 

(1)  Tool  Executable(s) :  ECL.EXe  (T) 

(2)  Dataoase(s):  to  be  identified 

(3)  operator  Aid(s):  do  tiles  tor  creating  tool 
and  global  file  descriptor  entries  in  tne 
*orns  Manager  database 

(4)  Documentation: 

•  Installation:  to  be  identified 

-  NSa-Specif ic:  to  be  identified 

-  Native  Host:  to  be  identified 

EMLOAD: 

(1)  Tool  Executable(s):  EMLOAD. EXE  IT) 

12)  Dataoase(s):  to  De  Identified 

(3)  Operator  Aid(s):  DO  files  tor  creating  tool 
and  global  file  descriptor  entries  in  the 
worxs  Manager  database 

(4)  Documentation: 

•  Installation:  to  be  Identified 

-  NSw-Specif lc:  to  De  identified 

-  Native  Host:  to  be  identified 


fr'MTBCPL: 
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(1)  Tool  Executable(s):  FMTBCPL.EXE  CT) 


(2)  Database(s):  to  be  Identified 

i3)  Operator  Aid(s):  oo  tiles  for  creating  tool 
and  global  file  descriptor  entries  in  tne 
works  Manager  database 

(4)  Documentation: 

-  Installation:  to  be  identified 

-  NS*-Specif i c:  to  be  identified 

-  Native  Host:  to  be  identified 

HP: 

(1)  Tool  Exeeutabie(s):  FTP. EXE  (T) 

(2)  Databasets):  to  be  identified 

(3)  Operator  Aid(s):  DO  tiles  tor  creating  tool 
and  global  file  descriptor  entries  in  tne 
works  Manager  database 

(4)  Documentation: 

•  installation:  to  oe  identified 

-  NSw-specif ic:  to  be  identified 

*  Native  Host:  to  be  identified 

HOSTAT: 

U)  Tool  Executable(s):  HOSTAT. EXE  (T)r 
NETSTAT.EXE  (T) 

(2)  Dataoase(s):  to  be  identified 

(3)  Operator  Aid(s):  DO  files  tor  creating  tool 
and  global  file  descriptor  entries  in  tne 
works  Manager  database 

(4)  Documentation: 


,iw  -V 

»-  vS 
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-  Installation:  to  be  identified 

-  NSw-Specif ic:  to  be  identified 

-  Native  Host:  to  be  identified 

iddt: 

(1)  Tool  Executable(s) :  IDDT, EXE  (T) 

(2)  Database(s):  to  be  identified 

(3)  Operator  Aid(s):  DO  files  for  creatlnq  tool 
and  qiobal  file  descriptor  entries  in  the 
works  Manaqer  database 

(4)  Documentation: 

•  Installation:  to  be  identified 

-  NSW-Specif ic:  to  be  identified 

-  Native  Host:  to  be  Identified 

jigsaw: 

(1)  Tool  Executable(s) :  JlGSAw.EXE  (T) 

(2)  Uatabase(s):  to  be  identified 

13)  Operator  Aid(s):  do  files  for  creating  tool 
and  global  tile  descriptor  entries  in  the 
works  Manager  database 

(4)  Documentation: 

•  Installation:  to  be  identified 

-  NSw-specif ic:  to  be  identified 

•  Native  Host:  to  be  identified 

LINKER: 

ll)  Tool  Executable(s) :  LINKER. EXE  (T) 
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(2)  Oataoase(s):  to  be  Identified 

13)  Operator  Aid(s):  DO  files  tor  creating  tool 
and  global  tile  descriptor  entries  in  tne 
Morks  Manager  database 

(4)  Documentation: 

-  Installation:  to  be  identified 

-  NSw-Speclf ic:  to  oe  identified 

-  Native  Host:  to  De  identified 

macro: 

11)  Iool  Executaoie(s) :  MACRO. EXE  (l) 

(2)  Database  is):  to  be  identified 

(3)  Operator  Aid(s):  DO  tiles  for  creatinq  tool 
and  global  file  descriptor  entries  in  tne 
*or<s  Manaqer  database 

14)  Documentation: 

-  Installation:  to  be  identified 

-  MSa-Specitlc:  to  be  identified 

-  dative  host:  to  oe  identified 

macro20: 

ID  Tool  Executaole(S) :  MACRO20.EXE  (T) 

12)  Database(s) :  to  be  identified 

(3)  Operator  Ald(s):  DO  tiles  tor  creating  tool 
and  global  tile  descriptor  entries  in  tne 
tforxs  Manager  database 

(4)  Documentation: 


Installation:  to  oe  identified 
NSw-Specitic:  to  oe  identified 


Native  Host:  to  oe  identified 


mkunoff : 

(1)  Tool  Executaoiets ) :  mrunoff.exe  (T) 

(2)  Dataoase(s):  to  be  identified 

(3)  Operator  Aid(s):  00  files  for  creatine  tool 
and  global  tile  descriptor  entries  in  the 
works  Manager  database 

(4)  Documentation: 

-  Installation:  to  oe  identified 

-  NSw-Speclf ic:  to  be  identified 

-  Native  Host:  to  oe  identified 

NETSTAT: 

(1)  Tool  Executable(S) :  NETSTAT.EXE  C T ) 

(2)  Oataoase(s):  to  oe  identified 

(3)  operator  Aid(s):  00  files  for  creating  tool 
and  global  file  descriptor  entries  in  the 
works  Manager  database 

(4)  Documentation: 

-  Installation:  to  oe  identified 

•  NSM-Speclfie:  to  oe  identified 

•  Native  Host:  to  be  identified 


PRIM: 

(1)  Tool  Executabie(s) :  prim. EXE  (T), 
10-SERVER-F0R-PR1M.EXE  tT).  GPM.EXE  it), 
UDDT.EXE  (T) 

(2)  Dataoase(s):  to  be  identified 

(3)  Operator  Aid(s):  do  files  for  creating  tool 
and  global  file  descriptor  entries  in  the 
works  Manager  database 
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(4)  Documentation 


*  installation:  to  oe  identified 

-  NSw-Specif ic:  to  be  identified 

•  Native  Host:  to  De  identified 

PSAVE: 

(1)  Tool  Executaole(s):  PSAVE.EXE  (T) 

12)  Database  Is ) :  to  be  identified 

13)  Operator  Aid(s):  DO  files  tor  creating  tool 
and  global  file  descriptor  entries  in  the 
wonts  Manaqer  database 

14)  Documentation: 

-  installation:  to  oe  identified 

-  Nsw-Specltic:  to  oe  identified 

-  Native  Host:  to  be  identified 

sos: 

(1)  Tool  t'xecutable(S):  SOS. EXE  (T),  SOSHLP.EXE 
CT) 

(2)  Dataoasels):  to  dc  identified 

(3)  Operator  Aid(s):  DO  files  tor  creating  tool 
and  global  file  descriptor  entries  in  the 
wonts  Manager  database 

(4)  Documentation: 

■  Installation:  to  oe  identified 

-  NSwSpecif lc:  to  be  identified 

-  Native  Host:  to  oe  identified 
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SPELLS 


(1)  Tool  Executable(s):  SPELL. EXE  (T) 

(2)  oataoase(s):  to  be  Identified 

13)  operator  Aid(s):  oo  flies  for  creatlnq  tool 
and  global  file  descriptor  entries  In  the 
MorKs  Manager  database 

(4)  Documentation: 

•  Installation:  to  be  Identified 

•  NSw-Speclf ic:  to  be  Identified 
-  Native  Host:  to  be  identified 


SKCCOMJ 

(1)  Tool  Executabie(s):  SRCCOM.exe  (T) 

(2)  Dataoasels ) :  to  be  identified 

13)  Operator  Aid(s):  do  files  for  creatlnq  tool 
and  global  file  descriptor  entries  in  the 
Norxs  Manaqer  database 

(4)  Documentation: 

-  Installation:  to  be  identified 

-  Nsw-Specif ic:  to  be  identified 

-  Native  Host:  to  be  identified 


TECO: 

(1)  Tool  Executable(S) :  TECO. EXEC  CT) ,  EXEC.EXE 
(T) 

(3)  Operator  Ald(s):  do  files  for  creating  tool 
and  global  flit  descriptor  entries  in  the 
nones  Manager  database 

(4)  Documentation: 
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-  Installation:  to  oe  identified 

*  Nsw-soecif ic:  to  De  identified 

*  Native  Host:  to  be  Identified 

(2)  DatabaseCs):  to  be  Identified 
UYK20 : 

Cl)  Tool  ExecutabieCs):  UYK20.EXE  IT), 

10-SERVER-K0R-PKIM.EXE  CT),  GPM.EXE  CT), 
UDDT.EXE  CT),  PRIM.EXE  CT) 

(3)  operator  Aid(s):  DO  files  for  creating  tool 
and  global  file  descriptor  entries  in  the 
worxs  Manaqer  database 

(4)  Documentation: 

*  Installation:  to  be  identified 

-  NSw-Specif ic:  to  be  identified 

-  Native  Host:  to  oe  identified 


U1 

(1)  Tool  Executaoiets ) :  u1050.EXE  CT), 

IO-SEKVER-FOR-PRIM.EXE  CT),  GPM.EXE  CT), 
UDDT.EXE  CT),  PRIM.EXE  (T) 

C 2 )  DatabaseCs):  to  be  identified 

C 3 )  Operator  Aides):  DO  files  for  creating  tool 
and  global  tile  descriptor  entries  in  the 
worxs  Manager  database 

C  4 )  Documentation: 

•  Installation:  to  be  identified 

•  Nsw-specif ic:  to  be  identified 

•  Native  Host:  to  be  identified 


lbl 


XEDS 


(1)  Tool  Exeeutabie(s) :  xed.exe(I) 

C 2 )  Databasets):  to  be  identitied 

i 3 )  operator  Aid(s):  Do  tiles  tor  creating  tool 
and  global  tile  descriptor  entries  in  the 
worics  Manager  database 

(4)  Documentation: 

*  Installation:  to  be  identitied 

•  NSw-Specit lc:  to  be  identified 
-  dative  Host:  to  be  identitied 
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Appendix  C 


Overvie*  of  the  nsw  help  Facility 


[Note:  The  overview  of  goals,  requirements  and  capabilities  of 
the  nsw  Help  Facility  (including  execution  examples)  which 
follows  was  extracted  from  "The  NS*  HELP  Facility  System 
specification"  bv  Peter  Kneiss  and  John  Dingman.  dated  February 
27.  1981.) 


nsw  Help  Facility 

The  ns*  system  consists  of  many  dissimilar  hosts  and 
internal  functions  supported  by  a  variety  of  development 
contractors.  Each  tool  purveyor,  host  operating  system 
developer,  and  each  NS*  contractor  documents  a  particular  concern 
independent  of  its  integration  in  NS*.  As  a  result,  the 
documentation  of  the  conglomerate  of  systems  that  is  seen  dv  the 
user  as  one  entity  originates  as  a  series  of  separate 
publications.  Because  the  documentation  for  various  aspects  ot 
NS*  nas  many  origins,  documentation  standards  cannot  be  imposed 
to  accomodate  the  HELP  facility.  Ratner,  the  HELP  facility  must 
function  as  a  delivery  facility  that  would  consolidate  access  to 
the  existing  documentation.  Thus,  the  following  broad  goals  were 
set  when  specifying  the  information  delivery  system  for  the  nsw 
^LP  facility: 

To  standardize  tne  user  interface  to  conform  with  other 
NS*  components 

To  centralize  information  in  one  source  instead  ot  many 
tools  tor  many  types  ot  information 

To  create  a  generalized  Interface  which  is  adaptable  to 
a  variety  ot  information  files 

To  create  a  facility  whose  tiles  and  topic  selection 
structure  can  be  externally  configured  by  an  NS* 

Operator  (i.e.,  to  have  tew,  if  any  parameters,  topics, 
etc.,  compiled  into  the  software  itself). 


In  addition,  there  were  two  functions  which  the  help 
facility  needed  to  provide  to  users: 

Enable  a  user  loqged  into  nSw  to  send  a  message  to  an  NSW 
operator  (who  is  not  necessarily  logged  in).  This  would 
allow  help  users  to  document  bugs,  make  requests,  or  ask 
procedural  questions  without  leaving  NSw.  In  particular, 
these  messages  could  pe  entered  during  the  times  an 
operator  is  not  available  bv  pnone. 

Display  the  status  of  NSw  hosts  so  users  can  be  informed 
wnen  remote  hosts  are  not  responding,  thus  avoiding  having 
to  wait  tor  connection  timeouts#  and  providing  affirmation 
tnat  long  running  tasks  are  actually  continuing  to  execute. 


Tne  help  facility  currently  installed  in  the  user  System 
satisfies  the  above  mentioned  goals.  It  aids  users  in  selecting 
the  type  of  information  needed  from  among  a  variety  of 
information  files.  At  tne  top  level  of  tne  interface,  the  user 
may  also  choose  to  send  a  message  to  Ups  (IELOPS)  or  display  the 
most  recent  status  of  NSw  hosts  (STATUS).  The  tool  is  designed 
for  flexibility  in  changing  the  topical  map  (e.g..  to  reflect 
changes  in  NSw)  and  for  adaptability  in  displaying  different 
information  files.  The  current  version  can  provide  a  single 
online  access  point  to  the  information  previously  provided  by  the 
USER  IMPACT  bULLETIN .  the  NSw  DOCUMENTATION  SUMMARY,  tne  NSW  USER 
REFERENCE  MANUAL,  the  NSW  tools  DESCRIBE  and  HELP-RM,  tne  RADC-20 
Command  INFORMATION  (about)  NSw-STATUS,  and  the  INTERIM  NSW 
MANAGER'S  TOOLS. 


Tne  following  typescript  illustrates  some  of  the  features 
of  the  help  facility.  A  dollar-sign  (S)  indicates  tnat  an 
<escape>  was  entered.  Tne  user's  lower  case  typein  can  usually 
be  distinqulsned  from  help's  uppercase  retyping  of  tne  command 
line.  It  snouid  be  noted  tnat  ail  of  the  menus  are  functions  of 
the  database  ratner  than  tne  program  and  can  be  cnanged  by 
altering  the  help  tiles.  Tne  only  compiled  In  commands  are 
"TELOPS",  "STATUS",  and  tne  display  commands  prompted  for  with 
"(H,p,s,E,  or  n *>". 

>  Our  comments  are  offset  In  this  manner 

>  The  following  typescript  hypothesizes 

)  that  a  naive  user  tries  to  use  a  tool 

>  and  encounters  a  problem.  He  attempts  to  "auit" 

>  nsw  and  encounters  one  of  tne  few  times  that  tne 

>  TOPS-24  Front  End  does  not  help  him  with  command 

>  syntax,  instead  of  tne  neiD  nsw  usually 

>  provides  in  response  to  an  escape#  ne 

>  receives  an  error  message. 
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>  *e  show  now  the  HELP  facility  would  lead  him  out 

>  of  his  quandary  if  the  Front  End  response 
»  Included  a  pointer  to  the  HELP  tool. 


nsw  user  System  Version  5.6) 

Report  problems  to  NSwoPSSRADC-23.  (315)333-6256. 

NSW :  use  qedx-rm$  (Confirm):  1 

»>  Tue  l 7-f eo-81  658 : i a : 47-PST:  No  rights  for  tool  QEDX-RM 
»>  Tue  17  Feb  1961  0810J49-PST  —  ICA.FE(WMTALK)) 

»  OEDX-RM  not  available 

NSW:  quits  NO  TOOLS  EXIST 

NSw:  ? 

options  are: 

COPY 

DELETE 

LOGOUT 

NET 

USE 

SEMAPHORE 

RENAME 

JOB 

PASSWORD 

FASTOUT 

SHOW 

ALTER 

MOVELOG 

QUIT 

RESUME 

(For  more  information,  type  "use  help") 
continue...! 
nsw: 


}  Taking  his  cue  from  tne  nsw  Front  End's 
>  response  to  a  question  mark*  the  user  invokes 
)  the  HELP  tool  and  types  "?" 

1  tor  a  list  of  HELP  topics. 


nsw;  use  helps  (Confirm):  ! 

(Connecting  to  2HELP. • • ) 

NSW  HELP  FACILITY 

Type  ?<CR>  tor  list  ot  topics 

HELP>? 
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Topics/commands  available  are 


COMMANDS 


describes  and  snows  examples  of  NSW  commands. 


News  -  allows  users  to  read  notices  and  news 

entered  by  NSMOPS  concerning  schedules, 
new  tools,  etc. 

POINTERS  •  displays  nsw  flies  whlcn  users  may  access  for 

additional  Information. 


0U1T  -  exits  tool  and  returns  to  NSW  command  level. 

STATUS  -  displays  current  status  of  NSW  hosts. 


TeLOPS  -  a  device  which  enables  NSW  users  to  send 

questions,  complaints,  or  comments  to  NSWOPS. 


TOOLS 


describes  nsw  tools,  outstandlnq  problems, 
and  tool  rights. 


Only  enouqh  of  a  command  to  make  it  unique  must  be  entered. 

Entering  "?"  will  snow  possible  commands/subcommands. 

Fields  (between  commands  and  subcommands)  must  be  separated  by 
a  space. 


For  example: 

■c  ?<CR>"  will  list  the  possible  subcommands  of  'COMMANDS*, 
"to  ?<CR>"  will  list  the  possible  subcommands  of  'TOOLS'. 


Use  the  following  characters  to  edit  your  input: 


<DEL>  - 

delete 

last 

character 

CTRL-W  - 

delete 

last 

word 

CTRL-U  - 

delete 

line 

CTRL-R  - 

retype 

line 

CTRL-V  - 

quote 

next 

character 

)  it  might  occur  to  a  user  who  nas  been  warned 

>  that  nsw  is  a  multi-host  system,  that  the  host  for 
)  his  tool  is  down.  The  HELP  facility's 

>  display  of  host  status  eliminates  that  possiblltv. 


HELP>status 


NSw  user  System  status  as  of:  13-Feb-81  1711-ESf 

USC-IS1E  (works  Manager  Host)  is  UP 
usoisic  (Tool  Bearing  Host)  is  UP 
RADOMULT1CS  (Tool  Bearing  Host)  is  up 
UCLA-CCN  (Tool  Bearing  Host)  will  be  down  until 
turtner  notice  due  to  system  upgrading. 


>  it  it  occurs  to  tne  user  to  cneck  tne  command 
)  "QUIT"  to  see  if  it  is  intended  to  end  NSw 

>  sessions,  the  following  might  ensue.  (The 

)  typescript  illustrates  help's  interpretation 
)  of  escape  and  question  mark.) 

HELP>commands$ 

COMMAND  NAME  (13  CHOICES) 

HELP>COM HANDS  quits 

QUIT  (NSw  COMMANO)  (4  CHOICES) 

HELP>COM HANDS  UU1T  ? 

QUIT  (NSw  COMMAND)  (4  CHOICES) 


DESCRIPTION  (OF  COMMAND) 
EXAMPLE  (OF  COMMAND  USES) 

NOTES 

EXCEPTIONS 

help>commands  QUIT  description 


COMMAND: 

PURPOSE: 

syntax: 

user 

QUIT 


quit  (NSW  Command)  (Id  lines)  (NURM  5.») 

End  a  pending  tool  instance. 


system  user  system 


use: 


tooiname  <name>  action 


(  ♦*  SUSPEND 
(  ABORT 

(  TERMINATE 


(End  of  items.) 


►  me  user*  having  seen  tne  four  topics 

>  under  tne  nSw  QUIT  command,  now 

}  can  use  a  minimi*  numoer  of  characters  to 
I  specify  displaying  "COMMAND  QUIT  NOTES" • 


HELP>C  q  n 

FUNCTIONAL  NOTES:  QUIT  ( NSw  Command  )  (27  lines)  (  NURM  b.a) 

1.  For  <name>  you  should  tvpe  tne  tool  instance  name.  Typinq  "?" 
at  this  point  will  yield  a  list  of  pending  tool  instances. 

2.  As  explained  in  tne  NSw  users*  Manual: 

[**  suspend  causes  tne  tool  to  cease  activity;  it  the  tool  permits* 
it  can  be  reactivated  (see  RESUME)  --  Not  yet  implemented.  **J 

abort  Kills  tne  tool  instance  immediately;  in  particular*  tiles 
which  nave  been  created  may  not  oe  delivered  into  NSw  tilespace. 

terminate  causes  appropriate  tools  to  enter  their  termination  code; 
whether  or  not  tiles  are  delivered  depends  on  tne  characteristics  of 
tne  tool. 

3.  If  SUSPEND  or  TERMINATE  is  not  meaningful  for  a  particular  tool 
tne  user  is  so  notified. 


(End  ot  items.) 


> 


>  It  an  information  file  contains  multiple 
topics  (as  indicated  ov  tne  presence  of  form 

>  feeds)*  HELP  offers  tne  four  display  options 

>  illustrated  below. 


HELP>c  g  exceptions 

QUIT  (NSw  Command) 

(H,P,S,E,  or  ?)*>? 

H 

p<CR>  (or  lust  <CR> ) 
Pn<CK> 

s 

E  (or  Ctrl-X) 

? 

(H,P,S,E, 


(3  items)  (uib  5.0] 


•  Snow  headers  ot  all  items 

-  Print  this  item 

•  Print  item  number  n 

-  skip  to  next  item 

-  Return  to  HELP  command  level 

-  Print  tnis  text 


or  ?)*>n 


1  -  Never  use  the  QUIT  command  on  a  CCN  Interactive  tool 

2  -  It  is  inadvisable  to  slew-away  from  a  tool  that  has  begun  a 

termination  sequence  (i.e.,  the  tool's  termination  command 
has  been  entered). 

3  -  The  following  sequence  of  messages  may  be  generated  when 

trying  to  QUIT  or  RESUME  a  tool-instance: 


(End  of  items.) 


(H.P.s.E,  or  ?)*>pl 

Never  use  the  QUIT  command  on  a  CCN  interactive  tool.  (e.g., 
DISPLAY-UC).  Instead  you  should  use  the  tool's  termination 
command  (e.g..  "END").  Frequently  as  a  consequence  of  uslnq 
QUIT  on  a  CCN  interactive  tool,  your  Front  End  is  damaaed 
and  NSW  is  unable  to  clear  the  CCN  systea  resources  tor  that 
tool-instance.  Since  these  resources  are  finite, 
tool-instances  which  QUIT  falls  to  clean-up  will  accumulate 
until  they  exhaust  the  available  NSW  resources  at  CCN. 
(NST-626)  (■  (NST-S92J 

— — o— - 


It  is  inadvisable  to  siew-awav  froa  a  tool  that  has  bequn  a 
termination  sequence  (l.e.»  the  tool's  termination  command 
has  been  entered). 

(H.P.s.E.  or  ? )*>s 

The  following  sequence  of  messages  aav  be  generated  when 
trying  to  QUIT  or  RESUME  a  tool-instance: 


(H.P.s.E.  or  ?)«>e 


>  If  the  user  went  on  to  retrieve  information  about 
)  tool  rights,  or  looked  up  the  error  message  in 

>  an  error  message  dictionary,  he  should  find 

)  that  his  real  problem  is  obtaining  rights  tor 
)  the  tool.  To  do  this  he  needs  to  coamunicate 

>  with  the  NSW  operator. 
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HFLP>tel0PS 


lype  Control-x  Ld  aoort,  "?<CP>H  for  neio. 

Please  enter  your  name 
a>Peter  Kneiss 

Enter  your  Project. Node  name 
=>gsq .admin 

Enter  your  net  address  (<CR>  if  none) 

=  >Knelsst<'radc-2fc> 

Enter  subject  (one  line  summary  of  problem  or  topic) 

=>Grant  rights  to  UFDX-RM 

Enter  your  message  below  on  as  many  lines  as  needed*  terminating 
your  input  with  Control-^  or  ESCAPE. 

Please  grant  GSG. admin  tne  rights  to  QEDX-rm. 

Thanks 

“Z 

Your  message  is  being  delivered  to  NSwoPS.  A  reply  win  be  sent  to 
you  soon.  Thank  you. 


HELP>quit$  (Confirm  UU1T) : 
nsw: 
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W  -  v  ■' 


,  1 


Appendix  D:  Sample  "weekly  Usage  Report" 


WEEKLY  USAGE  REPORT  FOR  THE  NSW  USER  SYSTEM 
(VERSION  5.0) 

From  MON  MAR  09  1981  0003EST  to  MON  MAR  16  1981  8000EST. 

I.  Mumper  oi  Logins: 

MON  TUE  WED  THU  FRI  SAT  SUN  *TOTAL* 

4102  1  7  0  0  30 

II.  Node  usage  Summary: 


PROJECT  *  NODE 

TOOLS  USED 


•  •  •»  m 

ACC 

♦  MIS 

13 

Logins  Totaling 

34:53:00 

•  ••• 

help: 

l 

Sessions 

Using 

03:00:86 

in 

00:44:80 

pli-pm: 

2 

Sessions 

Using 

03:00:04 

in 

00:12:00 

UEDX-RMJ 

3 

Sessions 

Using 

03:00:31 

in 

00:01:00 

run-rm: 

9 

Sessions 

Using 

03:08:36 

in 

00:48:00 

AFLC 

:  ♦  CRAIG 

3 

Logins  Totaling 

01:36:03 

help-rm: 

1 

Sessions 

Using 

88:08:84 

in 

00:12:00 

GSG 

♦  ADMIN 

3 

Logins  Totaling 

85:42:00 

PESCR1BE-1E: 

1 

Sessions 

Using 

83:00:31 

in 

00:02:00 

foktran-rm: 

1 

Sessions 

Using 

88:03:00 

in 

00:00:00 

ftp-1 e: 

1 

Sessions 

Using 

38:00:33 

in 

00:13:00 

help: 

l 

Sessions 

Using 

03:03:31 

in 

00:02:00 

XED-It: 

1 

Sessions 

Using 

03:00:83 

in 

00:12:00 

GSG 

♦  JRD 

3 

Logins  Totaling 

80:22:80 

help: 

6 

Sessions 

Using 

33:03:01 

in 

00:04:30 

GSG 

♦  KNE1SS 

9 

Logins  Totaling 

02:54:88 

SOS-R2J 

3 

Sessions 

Uslno 

80:00:54 

in 

00142:00 

xeu-ic: 

1 

Sessions 

Using 

08:00:88 

In 

00:01:00 

xed-ie: 

2 

Sessions 

Using 

08108:08 

in 

00:00100 

•  m 

XEO-R21 

6 

m  m 

Sessions 

UslnQ 

m  m  m  • 

88:00:04 

in 

m  m 

00136100 
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1  Logins  Totaling  190:27:30 


RADC  ADMIN 

no  tool  usage 


HADC  +  baskingkr  1  Logins  Totaling  00:56:30 

HELP:  1  Sessions  usinq  00:00:01  in  00:31:00 

run-rm:  l  sessions  Using  09:00:00  in  00:00:00 


Ill.  Tool  usage  Summary: 


TOTAL 

TOTAL 

TOTAL 

TOOLNAML 

SESSIONS 

CPU 

CONNECT 

DESCRIBE-IE 

1 

00:09:01 

09:02:93 

FORTRAN-K* 

1 

00:00:00 

99:00133 

FTP-IE 

1 

90:03:03 

99:13:90 

HELP 

10 

00:03:99 

91:21:90 

HELP-K" 

1 

00:00:34 

39:12:39 

PL1-RM 

2 

00:09:94 

93:12:99 

OEDX-K* 

3 

00:00:01 

93:01:99 

RUN-RM 

10 

30:09:36 

30:48:99 

S0S-R2 

3 

30:09:54 

39:42:99 

XED-IC 

1 

90:00:00 

39:01X00 

XED-Ifc 

3 

00:03:93 

09:12:99 

XED-R2 

6 

30:09:04 

99:36:93 

IV.  nsw  Up-time/Down-time  (*mh  oniy.  TBHs  excluded) 

The  following  conventions  will  pe  used  in  this  section: 


u-<Tl*E>  —  Time  nsw  came  up  Call  times  are  LST ) 
D*<TIme>  —  Time  ns*  went  down 

Number  in  parentheses  following  time  indicates  reason  nS* 
went  down,  usinq  the  following  codes: 


(1) 

-- 

1S1E  scheduled  downtime 

(2 ) 

mm 

Unknown  1S1E  system  failure 

(3) 

mm 

Known  NSw  failure 

(4) 

mm 

Unknown  nsw  failure 

(5  ) 

— 

Other 

A  single  asterisk  printed  under  any  day  means  the  system  was 


unavailable  the  entire  day. 
was  up  the  entire  day. 

A  douDie 

asterisk  means 

tne  system 

MON 

TUE 

MED 

IHU 

FR1 

••• 

mmm 

mmm 

mmm 

mmm 

U-1925 

D-1445C2) 

U-1635 

0-1130(2) 

U-1229 

t* 

0*9527(2) 
U-0998 
0*1459(2) 
U*l5i 0 

U-9836 

0-1809(2) 

162 


D-2136(2  ) 


SAT  SUN 

•••  mmm 

*  * 

Steve  Salisbury  (NS*»OPSPkADC-20) 


r 


addresses 


number  line 
of  copies  number 


Leon  McDowell 
wADC/ISCP 


RADC/TSLD 

GR IFF ISS  AFB  NY  13441 


-MbC/DAP 

OR  IFF ISS  AFB  NY  1344  1 


ADMINISTRATOR 
DEF  TECH  INF  CTR 
ATTN  i  DTIC-DDA 
CAMcRON  STA  BG  S 
ALEXANDRIA  VA  22314 

HQ  ESC  (XRZR) 

SAN  ANTONIO  TX  7d243 


HQ  ESC/DCX) 

SAN  ANTONIO  TX  78243 


HO  USAF/XOKT 
WASHINGTON  DC  20330 


HQ  USAF/RDST 
WASHINGTON  DC  20330 


HQ  USAF/RDPV 
WASHINGTON  DC  20330 


I 


21 


PENTAGON 

USbR&E,  RM  3D- 1  39 
ATTN*  TSCO 
WASHINGTON  DC  20301 


HQ  AFSC/DLAE 
ANLREWS  AFB  DC  20334 


HO  AFSC/XRK 
ANDREWS  AFB  DC  20334 


HO  SAC/NRI  (ST INFO  LIBRARY 3 
OFFUTT  AFB  NE  68113 


HQ  3246  TW/TETW 
cGl IN  AFB  FL  32542 


AFATL/DI.ODL 
HGLIN  AFB  FL  32542 


LiSVC/Pfc  (STINFO) 
PATRICK  AFB  FL  32V25 


TAFIG/IIPE  I  50 

LANGLEY  AFB  VA  23665 


HQ  TAC/XPS  ( STINFO ) ]  1  51 

LANGLEY  AFB  VA  23665 


HQ  TAC/XPJC  I  52 

ATTN*  Lt  Taylor 
LANGLEY  AFB  VA  23665 


TAFIO/IICJ  2  53 

ATTN*  Capt  John  Morrison 
LANGLEY  AFB  VA  23665 


0  55 


HQ  TAG/ ut.CG  I  56 

LANGLnY  AFB  VA  23665 


HQ  TAC/JRF  1  5B 

LANGLEY  AFB  VA  23665 


AFSC  LIAISON  OFFICE  I  59 

LANGLEY  RESEARCH  CENTER  (NASA) 

LANGLEY  AFB  VA  23665 


AFWL/NTYEE  (  C  E  BAUM  )  I  63 

KIRTLANL)  AFR  NM  87117 


AFWL/SUL 

ATI  N*  TECHNICAL  LIBRARY 
KIRTLANU  AFB  NM  87  I  I  7 


I 


64 


ASL/bNuGb 

ATI N *  CAPT  T  CLELAND 
WR  IGHT-PATTeRSON  AEB  OH  454  33 


ASL/eNcGh 

ATTN*  MR  LARRY  WEAVER 
WR IGHT-PATTERSON  AFB  OH  454  33 


ASU/XRb 

WR IGHT-PATTERSON  AFB  OH  45433 


I 

AFIT/LOb  -  TECHNICAL  LIBRARY 
BUILJING  640,  AREA  B 
WR IGHT-PATTERSON  AFB  OH  45433 


AFHRL/OTN 

WILLIAMS  AFB  AZ  B5224 


AFHRL/OA 

BROOKS  AFB  TX  78235 


AUL/LSb  67-342 
MAXWELL  AFB  AL  36112 


HO  AFCC/DAPL 

BLUO  P-40  NORTH,  RM  9 

SCOTT  AFB  IL  62225 


HO  AFCC/EPh 
SCOTT  AFB  IL  62225 


AFHRL/LRT 

LOWRY  AFB  CO  80230 


3300  rrw/rrGX 

KEt.Sf.Lrt  AFB  MS  39534 


DEFENSE  INTELLIGENCE  AGENCY 
ATTN «  RSE-2  (LT  COL  SCHWARTZ) 
WASHINGTON  DC  20301 


DEFENSE  INTELLIGENCY  AGENCY 
ATTN i  RSM-I 
WASHINGTON  DC  20301 


CODE  rt 1 23  TECHNICAL  LIBHAHY 
DEFENSc  COMMUNICATIONS 
ENGINEER ING  CENTER 
I860  WIEHLE  AVENUE 
rttSTON  VA  22090 

DIRECTOR 

DEFENSE  NUCLEAR  AGENCY 
ATTN  i  TIL 
WASHINGTON  DC  20305 


CHIEF,  C3  DIVISION 
DEVELOPMENT  CENTER,  MCDEC 
ATTN i  R  S  HARTMAN 
OUANTICA  VA  22134 


AFLMC/LGY 

ATTN «  MAJOR  MORGAN 
GUNTER  AFS  AL  36  M4 


DIRECTOR 

HMD  ADVANCED  TECHNOLOGY  CENTER 
ATTN i  ATC-P,  CHARLES  VICK 
PO  BOX  1500 
HUNTSVILLE  AL  35807 


EOARD/CMI 

TECHNICAL  LIBRARY  FL  2878 
BOX  14 

FPO  NY  09b 10 


COMMAND ING  OFFICER 
NAVAL  AVIONICS  CENTER 
LIBRARY  -  CODE  765 
INDIANAPOLIS  IN  46218 


NAVAL  TRAINING  EQUIPMENT  CENTck 
TECHNICAL  INFORMATION  CENTER 
ORLANDO  FL  32813 


COMMANDER 

NAVAL  OCEAN  SYSTEMS  CENTcK 

ATTN »  TECHNICAL  LIBRARY,  COUc  4473B 

SAN  DIEGO  CA  92152 


SUPERINTENDENT  (CODE  1424) 
NAVAL  POSTGRADUATE  SCHOOL 
AONTERcY  CA  93940 


COMMANDING  OFFICER 
NAVAL  REScARCH  LABORATORY 
COLE  2627 

WASHINGTON  DC  20375 


RddSTONE  SCIENTIFIC  INFORMATION  CENTER 
ATTN i  DRSM I-RPRJ 
US  ARMY  MISSILE  COMMAND 
REDSTONE  ARSENAL  AL  35809 


JOT/FAA  TECHNICAL  CENTER 
ARD-142  (ATTN*  A  k  CIOFFI) 
ATLANTIC  CITY  NJ  0o405 


NATIONAL  CENTER  FOR  ATMOSPHERIC  RESEARCH 
MESA  LIBRARY 
PO  BOX  3000 
BOULDER  CO  80307 


A  Ik  FORCE  ELEMENT  (AFELM) 
THE  RANl)  CORP 
1700  MAIN  STREET 
SANTA  MONICA  CA  904  06 


JR  R4YNEK  K  ROSICH 
ELECTRO  MAGNETIC  APPLNS , 
C/(;  7031  PIERSON  STREET 
ARVAJt  CO  80004 


AElC  LIBRARY  (TECH  FILtS) 
ARNOLD  A FS  TN  37389 


Director 

National  Security  Aqency 
ATTN*  TI2I3/TDL 
Fort  Meade  MD  20755 


Jirec  tor 

National  Security  Aqency 

ATTNi  W07 

Fort  Meade  MD  20755  v 


Director 

National  Security  Aqency 

A  TI  N  *  W3 1 

Fort  Meade  MD  20755 


Director 

National  Security  Agency 

ATTN*  R03 

Fort  Meade  MD  20755 


Dir ector 

National  Security  Aqency 
ATTN*  R I 

Fort  Meade  MD  20755 


Director 

National  Security 
ATTNi  R2 

Fort  Meade  MD  20755 


INC 


DL-7 


director 

National  Security  Aqency 
ATTN*  R5 

Fort  Meade  MU  207 55 


director 

National  Security  Aqency 
ATTN  *  R6 

Fort  Meade  MU  20755 


director 

National  Security  Aqency 
ATTN  i  R7 

Fort  Meade  MU  20755 


director 

National  Security  Aqency 
ATI  N  J  Rb 

Fort  Meade  MU  20755 


Colonel  Larry  Druffel 
arpa/itto 

1400  Wilson  Blvd 
Arlington  VA  22209 


HQ  ESu/FAt,  STOP  27 
HANSCOM  AFB  MA  01731 


ESL/UCKU  (STOP  53) 
ATI  N «  f.T  COMBS 
HAN SCUM  AFH  MA  0173! 


HQ  HSU/YSEA 
HANSCOM  AFB  MA  01731 


uSU/XrttT 

HANSCOM  ArM  MA  01731 


HSU/XrtWS  I  ;  78 

HAN 3COM  AFB  MA  01731 


cSb/XHWT  I  1 7y 

HANSCOM  AFB  M A  01731 


FSl j/XriMV  |  180 

HANSCOM  AFB  MA  01731 


iSb/XRTR  1  181 

ilANSCOM  AFB  MA  01 731 


FISL/XR  I  ]  84 

HANSCOM  AFB  MA  01731 


FISO/UC  R-3E  J  \ti5 

ilANSCOM  AFB  MA  01731 


HQ  cSD/YSM  (STOP  18)  2  186 

HANSCOM  AFB  MA  01731 


HQ  ESD/UCR-1S  1  187 

rian scorn  AFB  MA  01731 


HQ  eSU/UCH-II  I  188 

HANSCOM  AFB  MA  01731 


DL-9 


HSb/TOHR  (Caot 
HANSCOM  AFB  WA 


Cliff  Gardner) 
01731 


2  3 


APlC/LOtC  (Caot  Bill  Piski)  2 

ilHlGHT-PATTbrfSON  AFB  OH  454  33 


Wrt-ALC/MMRCUM  (Palmer  Craiq)  3  5 

HOblNd  AFB  GA  31098 


SM-ACC/MMeCF  (Van  Johnson)  3  6 

McCCcLLAN  AFB  CA  95652 


OC-ALC/MMHC  (Mike  Parish)  3  7 

TINKFH  AFB  OK  73145 


DL-10 


. 


